DBSor, DBSor, je pense qu'il y a plus pro que moi ici, n'est-ce pas
guillôme et son célèbre
MACoinche 
macgic a fait un bon résumé de la situation.
Programmer, c'est simple, surtout sur MacOS où tout est fourni, bonne documentation et une communauté toujours prête à donner un coup de main.
Pour vous faire une idée, j'ai commencé à programmer en basic sur oric1 (vers 1982-83), puis en assembleur 6502 (des jeux déjà
)
Puis C et Pascal à l'école d'ingé, stages sur Think C et Think Pascal (sur Mac), passage sur 4D (bases de données), puis l'enfer, à l'armée, un an de borland C++ sur windows 3.1. J'y ai quand même découvert la philosophie du langage C++ à travers le livre de son inventeur,
Bjarne Stroustrup. Rigolo mais bon, pas nécessaire
Puis CodeWarrior (C et C++) en thèse, pour s'amuser car je trouvais MatLab trop lent
Puis rien jusqu'en juillet 2005, où j'ai acheté le livre
Cocoa par la pratique, excellent livre pour débuter en Cocoa (routines MacOS).
Donc pour le php, le java, etc, je me tairais, je n'y connais rien
Pour programmer une application sur MacOS, je ne saurais trop conseiller l'objective-C (langage de développement issu de Next) avec les API Cocoa, c'est simple à la condition de connaître les bases du C. Si ce n'est pas le cas, acheter un petit bouquin pour les bases (les boucles, les variables, les tests, etc). Le résultat, compilé, est plus rapide qu'en java. De plus, le passage vers intel ne devrait pas poser de problème (en mettant à jour son xcode, ADSL obligatoire). Mais ce ne sera pas compatible windows
Le C++ ne sert à rien, mais la philosophie du langage object est à connaître, c'est très simple:
Petit cours de langage objet en objective-CTout d'abord, il y a les classes d'object, prenons un exemple, les chaussettes.
Puis il y a les instances, ce sont les objects en particulier, par exemple mes chaussettes, ou celles d'Ogur.
La classe définit des membres, par exemple la laine, la couleur, les trous.
Elle peut aussi définir des actions, par exemple mettre ou repriser.
D'autres classes peuvent être créées (sous classes) et héritent de tout le travail déjà effectué avec la classe mère, c'est pratique.
Traduit en Objective-C simplifié
@interface Chaussettes // définition de la classe
{
id laine;
id couleur;
id trou;
}
- (BOOL)a_des_trous; //renvoie oui ou non (YES or NO) selon le cas
- (void)mettre;
-(void)repriser;
...
il faut bien sûr définir tout ce que cela fait...
Puis quand on en a besoin
Chaussettes* les_chaussettes_d_ogur; //une paire de chaussettes en particulier
if ([les_chaussettes_d_ogur a_des_trous] == YES) //ici, il faut connaître le C
[les_chaussettes_d_ogur repriser]; //action conditionnelle sur l'instance de Chaussettes
[les_chaussettes_d_ogur mettre]; //action inconditionnelle sur l'instance de Chaussettes
et voila, Ogur est certain de ne plus mettre des chaussettes trouées
Plus sérieusement, Cocoa définit par exemple une classe fenêtre que l'on peut sous-classer en sous-classe fenêtre_à_moi_qui_affiche_des_choses, et associer une instance de cette nouvelle classe aux documents que l'on ouvre, etc etc..... Et puis il y a Interface Builder, fabuleux outil pour créer les interfaces, etc etc
Par contre, j'attire l'attention de ceux qui veulent s'y mettre, c'est prenant, très prenant, WoW est du pipi de chat à côté de ce passe-temps, donc prudence. Par contre, c'est certainement meilleur pour les neurones
Plus je xcode est plus je deviens nul au rifle, plus je CoD et plus je retarde la sortie de iClanASC...
En tout cas, n'hésite pas à me soumettre tes interrogations, et lis les archives des forums, un bon point de départ est le forum MacBi, et ce
topic qui fournit tout un tas de liens...
, étant un novice presque absolu en la matière...
).
Merci ma poule