Discussion :

[Abawell]

Je te remercie pour l'explication mais je pense que tu as partiellement tort. Parce que finalement le nom interne n'est jamais exposé, il ne fait pas partie de la signature publique, seul le nom externe en fait partie. Donc le nom interne est bien réservé au seul usage du compilateur et des langages comme Java ou C# pourraient tout à fait être utilisés pour consommer les API existantes (il est d'ailleurs possible de nommer certains arguments lors de l'appel, par exemple x = func(someBoolean: true)).

En revanche il est clair que si on veut laisser au développeur la possibilité d'avoir deux noms, un public et un privé, pour chaque paramètre d'une fonction, alors il fallait un nouveau langage mais cette fonctionnalité semble tellement accessoire et obsolète, datant des 80 colonnes et d'avant la complétion automatique...

Oui, c'est ce que j'ai écrit, le nom interne n'est utilisé qu'en interne à la fonction. La méthode est appelé qu'en utilisant le nom externe.

Mais désolé, j'ai donné un mauvais exemple en utilisant un nom de méthode privé.

Si c'est pour une méthode que tu écris toi même. Tu fais ce que tu veux. Tu peux demander de ne pas avoir de nom externe et alors tu appels ta fonction avec la même syntaxe que celle que tu utiliserais en C ou en C#

le problème provient des centaines de méthodes de Cocoa qui doivent pouvoir être appelées depuis le code.

J'en prend une au hasard. classe UIView, méthode insertSubview:atIndex:

En Swift tu écris:
myView.insertSubview(mySubView, atIndex:2);

En C# tu l'écris comment sachant que le compilateur doit générer la string insertSubview:atIndex: pour retrouver le bon sélecteur (voir @selector).

[DonQuiche]

En Swift tu écris:
myView.insertSubview(mySubView, atIndex:2);

En C# tu l'écris comment sachant que le compilateur doit générer la string insertSubview:atIndex: pour retrouver le bon sélecteur (voir @selector).

Tu l'écris exactement de la même façon et tu charges le compilateur d'émettre la chaîne correspondante.

[Abawell]

Tu l'écris exactement de la même façon et tu charges le compilateur d'émettre la chaîne correspondante.

Jusqu'à preuve du contraire, cette syntaxe n'est pas du C#.

Après on peut toujours écrire un compilateur qui accepte un langage proche du C# en prétendant que c'est du C#, ça n'en reste pas moins un autre langage.

Tu voulais une contrainte syntaxique, je te la donne, tu ne la vois pas après je peux plus rien pour toi.

[DonQuiche]

Jusqu'à preuve du contraire, cette syntaxe n'est pas du C#.

La preuve du contraire.
C'est ce que j'avais expliqué précédemment : il est possible en C# de nommer les arguments. C'est notamment prévu pour les paramètres optionnels mais c'est aussi applicable à tout argument.

[Abawell]

Et donc tu détournes une option du C# de nommer des arguments (qui peuvent dans ce cas être données dans n'importe quel ordre) pour satisfaire une obligation de Cocoa pour retrouver la signature d'une méthode.
Du bidouillage tout ça.
En Swift, le nom externe n'est pas une facilité donné au programmeur pour fournir ses paramètres comme il le désire. Le nom externe du paramètre fait parti du nom de la méthode.

[foetus]

Par contre une question pour les pommeux svp : il y a un an de cela environ Apple mettait fin à la gestion automatique de la mémoire au profit du comptage de références en forçant tout le monde à réécrire son code et en jurant leurs grands dieux que c'était l'avenir et indispensable. Techniquement ce revirement fait sens mais c'était attendu ou bien ça vous tombe encore dessus sans crier gare ?

Tu te trompes : avec le compilateur maison Apple, c'est [quasi] exactement la même chose mais le compilateur rajoute à ta place les appels release.
Il y a un analyseur de code qui permet de savoir quand libérer les variables.
Les seules différences ce sont la notion d'appartenance faible/ forte (notamment nécessaire pour les blocks qui est une nouveauté de iOS5 ou 6 qui est arrivé en même temps) et 2-3 mots clefs comme @autoreleasepool.

Non ce sont les storyboards qui sont [quasi] obligatoires, contrairement à ARC qui lui est facultatif

Accessoirement y a t-il une raison technique à ce qu'ils aient créé leur propre langage? Y avait-il des besoins spécifiques pour la compatibilité avec Objective-C que les autres langages ne pouvaient satisfaire (notamment Java ou C#) ?

Oui de maitriser toute la chaine de développement et de faire ce qu'il veule: de l'IDE (XCode + Interface Builder), du langage, du compilateur/ linker (Clang + LLVM) à l'exécutable.

Et même avec Switch, il supprime la dépendance libC (du moins c'est ce que je pense) et donc dépendance en moins et performances en plus

Non, sérieux, tu as vu Roselyn et toutes les améliorations qui vont être encore apportées ? Tu es au courant que c'est tellement vieillissant qu'ils vont permettre de le compiler en natif ?

La compilation c'est juste normal Parce que le gros problème c'est la VM
La VM ne permet pas de libérer les ressources en temps réel (peut-être qu'il y a des techniques pour) et surtout elle rallonge les temps d’initialisation.
Peut-être il y a d'autres trucs.

Donc compiler en natif permet de gagner des performances un peu partout:
Et peut-être portable dans certains cas.

De toute façon le VM est tellement un problème que Microsoft va faire un kernel (Midori) qui est la VM

[sekhmet]

pour ceux qui veulent aller jeter un oeil, Apple a sorti un bouquin gratuit
https://itunes.apple.com/us/book/swi...ign-mpt=uo%3D4
ça a l'air pas mal !

[DonQuiche]

Et donc tu détournes une option du C# de nommer des arguments (qui peuvent dans ce cas être données dans n'importe quel ordre) pour satisfaire une obligation de Cocoa pour retrouver la signature d'une méthode. Du bidouillage tout ça.

C'est simplement qu'en C# tout paramètre a un nom externe.

Mais bon, peu importe : de toute façon le comptage de références justifiait un nouveau langage comme je l'ai expliqué.

Le nom externe du paramètre fait parti du nom de la méthode.

Mais il ne fait pas partie de la signature si je ne m'abuse (impossible de déclarer deux méthodes identiques en se distinguant que par le nom du paramètre). C'est donc un simple détail d'implémentation.

Tu te trompes : avec le compilateur maison Apple, c'est [quasi] exactement la même chose mais le compilateur rajoute à ta place les appels release.
Il y a un analyseur de code qui permet de savoir quand libérer les variables.

Non je ne me trompe pas, c'est sur ton "quasi" que nous ne sommes pas d'accord. Parce qu'il y a toutes les nombreuses fois où le compilateur ne peut pas gérer ça automatiquement.
En revanche là où je me suis trompé et que j'ai détaillé plus tard c'est que Swift conserve un comptage des références et que c'est même pour cela que Apple a créé un nouveau langage.

Oui de maitriser toute la chaine de développement et de faire ce qu'il veule: de l'IDE (XCode + Interface Builder), du langage, du compilateur/ linker (Clang + LLVM) à l'exécutable.

Rien n'interdit de garder le contrôle sur l'outillage quel que soit le langage que tu prends.

La VM ne permet pas de libérer les ressources en temps réel (peut-être qu'il y a des techniques pour) et surtout elle rallonge les temps d’initialisation.

Le terme "VM" n'est utilisé qu'en Java et c'est un très mauvais choix de mots vu que tout le monde le comprend de travers. Ce terme recouvre plusieurs choses :
* Une API Java faisant le pont avec les fonctions du système (ex: Swing pour créer des fenêtres, quel que soit le système). Sauf dans les cas où les appels sont directs (ex: C# avec les nouvelles API Windows). Cela ne disparaît pas en compilant (sauf méthodes triviales) et de toute façon ça ne pose aucun pb de perfs (tu ne crées pas assez de boutons et de fenêtres par seconde pour que ce soit significatif).

* Un allocateur, un ramasse-miettes et quelques autres algorithmes. Cela ne disparaît pas en compilant, pas plus que tu ne peux supprimer libc en obj-c. Même si dans bien des cas tu peux éviter d'inscrire un objet dans le ramasse-miettes : exactement les cas où le comptage de références peut être supprimé.

* Le compilateur JIT. Ça ça peut être viré et un compilateur AOT peut faire de meilleures optimisations. C'est tout l'intérêt.

De toute façon le VM est tellement un problème que Microsoft va faire un kernel (Midori) qui est la VM

Microsoft réalise un OS où tout code a certains comportements vérifiables (notamment son isolation mémoire), offrant ainsi une sécurité par la preuve plutôt que par une coûteuse isolation logicielle. Ce qui permet de tout faire tourner en ring0, de rendre quasi-instantanés les appels au système, notamment pour une concurrence plus granulaire, et de virer des pelletées de surcouches de sécurité tout en offrant une meilleure sécurité.

[Abawell]

Mais il ne fait pas partie de la signature si je ne m'abuse (impossible de déclarer deux méthodes identiques en se distinguant que par le nom du paramètre). C'est donc un simple détail d'implémentation.

Relis ce que j'ai écrit. C'est très précisément ce que j'ai dit depuis le début. Le nom externe du paramètre fait parti de la signature.

En Objective-C, on peut avoir deux fonctions

-(void)addNumber:(int)value1 withInt1:(int)value2;
-(void)addNumber:(int)value1 withInt2:(int)value2;

leur signature, se qu'on appel le sélecteur en objective-C est addNumber:withInt1: et addNumber:withInt2:

en Swift elle vont être déclarées

func addNumber(value1:Int, withInt1 value2:Int)
func addNumber(value1:Int, withInt2 value2:Int)

ont peut aussi simplifier en utilisant le nom local comme nom externe.

func addNumber(value1:Int, withInt1:Int)
func addNumber(value1:Int, withInt2:Int)

Et ce ne sont pas les même fonctions. Elles peuvent être déclarées toutes les deux dans la même classe (ou structure, ou enum).

L'appel des fonctions s'écrira

myClass.addNumber(12, withInt1:42)
myClass.addNumber(12, withInt2:42)

[foetus]

Rien n'interdit de garder le contrôle sur l'outillage quel que soit le langage que tu prends.

Contre exemple: Google et Android.

Même Microsoft fait comme Apple : langage, IDE, framework, format spécifique

Le terme "VM" n'est utilisé qu'en Java et c'est un très mauvais choix de mots vu que tout le monde le comprend de travers. Ce terme recouvre plusieurs choses :
* Une API Java faisant le pont avec les fonctions du système (ex: Swing pour créer des fenêtres, quel que soit le système). Sauf dans les cas où les appels sont directs (ex: C# avec les nouvelles API Windows). Cela ne disparaît pas en compilant (sauf méthodes triviales) et de toute façon ça ne pose aucun pb de perfs (tu ne crées pas assez de boutons et de fenêtres par seconde pour que ce soit significatif).

* Un allocateur, un ramasse-miettes et quelques autres algorithmes. Cela ne disparaît pas en compilant, pas plus que tu ne peux supprimer libc en obj-c. Même si dans bien des cas tu peux éviter d'inscrire un objet dans le ramasse-miettes : exactement les cas où le comptage de références peut être supprimé.

* Le compilateur JIT. Ça ça peut être viré et un compilateur AOT peut faire de meilleures optimisations. C'est tout l'intérêt.

Oui je suis au courant. Mais lorsque tu vois que depuis 2005 (à la grosse louche), les grosses boites se penchent sur des compilateurs (JIT et AOT maintenant) et différentes techniques d'optimisation c'est qu'il y a un problème quelque part.
Je suis tout cela d'un œil, mais cela fait presque peur comment ils suent pour grignoter un peu de performances un peu partout mais surtout au démarrage.
J'ai même vu que Microsoft a l'ébauche d'un compilateur Javascript
Lorsque tu vois les spécifications techniques des ordiphones [smartphones] Android et celles des iPhone, tu rigoles
N'empêche Microsoft s'en sort mieux avec Windows Phone 8.

Et oui parce que pour les applications sur ordinateurs, il n'y a quasi jamais de problème [sauf du code bogué].
Mais lorsque tu passes à un environnement distribué/ serveur assez conséquent ou sur de l'embarqué, ce n'est pas pareil

Par contre effectivement je ne sais pas comment le ramasse-miettes et autres spécifiés sont gérés "en natif"

Microsoft réalise un OS où tout code a certains comportements vérifiables (notamment son isolation mémoire), offrant ainsi une sécurité par la preuve plutôt que par une coûteuse isolation logicielle. Ce qui permet de tout faire tourner en ring0, de rendre quasi-instantanés les appels au système, notamment pour une concurrence plus granulaire, et de virer des pelletées de surcouches de sécurité tout en offrant une meilleure sécurité.

Le code managé tourne en ring0 mais il est sandboxé quand même (il est isolé de tout).
Il y a une notion de contrats ou peut-être de permissions pour des communications inter-process ou avec les bibliothèques systèmes.

Et le code non managé (C, C++) lui ne tourne pas en ring0

Il y a la notion de mémoire qui va changer: il n'y aura plus de pages par exemple.

Mais bon tout cela pour dire que le plus simple pour optimiser du code managé ... c'est de refaire l'OS

[palmipod]

Hello

Swift fonctionne très bien pour des application OSX, pas uniquement pour iOS. Il bénéficie déjà de toutes les API d'Apple (Cocoa, etc...)
Son avantage c'est qu'il est beaucoup plus compréhensible qu'Objective C, assez élégant (ça n'engage que moi) avec un peu de fonctionnel.
Du coup le développement d'apps OSX+iOS s'ouvrent à beaucoup plus de monde, alors sans parler de démocratisation (reste la machine à acheter mais c'est un autre débat) je trouve le projet plutôt sympa (j'avais abandonné l'apprentissage d'Objective-C) et tout le monde risque de s'y retrouver. A suivre, pour voir si la qualité des apps sera au rendez-vous ou pas. Mais je trouve que l'on a un beau jouet et une vraie nouveauté.

[DonQuiche]

Mais lorsque tu vois que depuis 2005 (à la grosse louche), les grosses boites se penchent sur des compilateurs (JIT et AOT maintenant) et différentes techniques d'optimisation c'est qu'il y a un problème quelque part.

Le problème c'est qu'on est passé du desktop à l'embarqué. Quand ta cafetière doit faire tourner du JS et du Java, ça change un peu la donne. Et puis plus généralement, l'état de la sécurité informatique étant ce qu'il est, il y a une volonté d'étendre des langages de haut niveau à l'OS lui-même. Sans parler de la stagnation de la puissance par cœur.

Par contre effectivement je ne sais pas comment le ramasse-miettes et autres spécifiés sont gérés "en natif"

Quand tu appelles malloc en C tu appelles un algorithme allocateur qui meut tout un bazar. Et bien de la même façon avec un code géré les instanciations invoquent une fonction qui meut tout un bazar. La fonction est simplement plus complexe dans le second cas. Pré-compilé ou compilé à la volée ça ne change strictement rien de ce point de vue : le résultat final est le même appel de fonction.

En revanche un bon compilateur AOT est capable de détecter que certaines instances ne sont utilisées que localement et de supprimer le mécanisme de gestion de la mémoire, qu'il s'agisse de comptage de références ou d'un ramasse-miettes.

Le code managé tourne en ring0 mais il est sandboxé quand même (il est isolé de tout).

Tu n'as plus besoin d'aucune forme d'isolation logicielle ! Et tu peux totalement virer la mémoire virtuelle (sauf si tu veux faire un code non-managé mais c'est pas le but à terme). Maintenant étant donné que c'est un OS pour le nuage, MS souhaite sans doute se montrer paranoïaque et conserver une isolation au moins pour les premières années, au cas où il y aurait un bogue dans la poignée de milliers de lignes en C/asm.

Il y a une notion de contrats ou peut-être de permissions pour des communications inter-process ou avec les bibliothèques systèmes.

Étant donné que la communication inter-processus viole par définition l'isolation mémoire (c'est le seul point en plus du micro-noyau pouvant permettre une faille inter-processus), ces contrats servent à restaurer deux garanties :
* Partage par copie (sauf exception pour de gros tampons/buffers)
* Entente sur l'ordre de synchronisation pour éviter un interblocage (deadlock).

Et le code non managé (C, C++) lui ne tourne pas en ring0

Je crois que le but à l'avenir est de supprimer le code non-managé en autorisant seulement des langages de haut-niveau ou intermédiaires (comme M#). A priori le code non-managé devrait en fait tourner dans une copie de l'OS (un OS dans l'OS).

Mais bon tout cela pour dire que le plus simple pour optimiser du code managé ... c'est de refaire l'OS

Le but premier c'est avant tout de partager un même serveur entre plusieurs applis Windows sans avoir besoin de virtualisation. Le code managé n'est qu'un moyen pour ça, que les langages de bas niveau ne permettent pas. Il ne s'agit pas de modifier l'OS pour accélérer le code managé mais de se restreindre au code managé pour accélérer l'OS !

Ensuite le ramasse-miettes ne devient pas plus rapide sous prétexte qu'il est dans le dossier system32. Simplement les coûteux mécanismes de sûreté qui étaient nécessaires au code non-managé peuvent être levés avec un code dont l'isolation est prouvable.

[gabriel.klein]

Objective-C était très mal conçu. Un mélange de différentes logiques. Je devenais nerveux en l'utilisant
Apple aime rendre la vie des utilisateurs simple... mais aime créer des cauchemarde pour les développeurs.

J'espère que Swift sera mieux (pas encore testé).

Par contre comment seront adapté les librairies existantes?

[Le Vendangeur Masqué]

PAR LE POUVOIR DU TROLL ANCESTRAL !!!!!!!!!!!!!!!!!!!!!!

Ah bah oui les premiers messages étaient joyeusement trollesques. Dans le top du bêtisier j'ai d'ailleurs adoré le gars qui nous explique qu'il faut surtout pas se mettre et passer à autre chose parce qu'il pourrait rester encore quelques bugs dedans.

Non, sérieux, tu as vu Roselyn et toutes les améliorations qui vont être encore apportées ? Tu es au courant que c'est tellement vieillissant qu'ils vont permettre de le compiler en natif ? Que JAVA essaye de le rattraper (voir les annonces pour JAVA 8, 9 et même 10 sur developpez.net, rubrique JAVA) ? Regarde ce qu'il se passe autour de ton écosystème avant de commenter, s'il-te-plaît !

Deux choses:
1/ Java ça ne concerne plus le monde Apple (ou presque). Inutile d'imaginer qu'Apple aurait repris le langage propriété d'Oracle, avec toute l'incertitude juridique qu'il y a derrière. À ce propos les ennuis pour Google sont loin d'être terminés…
2/ Compiler en natif c'est ce que fait C (et donc ObjC/Swift) depuis toujours. Quelle avance pour Java…
20 ans pour ce rendre que finalement les machines virtuelles c'était peut-être pas ce qu'il y a de mieux, ça commence à faire beaucoup.

C'est bien dommage, de nombreux tests le trouve meilleur que JAVA sur bien des points. JAVA, c'est bien l'un des langages le plus utilisé, non ? Il est disqualifié aussi ? De plus, rien ne prouve que Swift sera si optimal que cela.

Etre meilleur que Java c'est tout sauf une référence. N'importe quel langage compilé (ou presque) fait mieux. Pour Swift on sait qu'il fait mieux qu'ObjC, sachant que ce dernier fait mieux qu'un bricolage sous Xamarin, je te laisse en tirer la conclus

Heu, tu connais les applis web ? Et depuis quand toutes les applis dans les autres langages sont gratuites ?

Les applis Web c'est pas un marché très tangible, on est à des années-lumières en terme de revenu par rapport à l'AppStore d'Apple.
Quand aux autres langages, je ne dit pas que développer en java fait gagner moins ça n'aurait pas de sens, je dit juste qu'utiliser les outils d'Apple (Xcode+Cocoa+hier ObjC aujourd'hui Swift) c'est la voie la plus simple et la plus efficace pour s'adresser au plus gros marché d'applications existant.

Soyons clair, je ne critique pas Swift car il n'y a pas encore assez d'informations pour cela (je n'ai pas encore lu les guides édités par Apple). Bref, Le Vendangeur Masqué, ton post n'est qu'un bon gros troll inutile.

Non je ne fais que répondre à des messages bien trollesques eux, et auquel toi tu t'es bien garder d'apporter la critique.

[Le Vendangeur Masqué]

Justement j'aimerais que tu les mentionnes car elles ne me semblent pas évidentes et je ne vois pas en quoi C# est vieillissant. S'il y a des innovations intéressantes dans ce langage ou des choses sortant de l'ordinaire je serais ravi de les découvrir mais je ne vois que du conventionnel.

Tu vois pas en quoi un langage conçu il y'a plus de 20 ans et qui s'est alourdi en fonctionnalités et en instructions d'années en années pourrait être vieillissant.
Or un langage de programmation c'est exactement la même chose qu'un logiciel ou du matériel. On peut le faire évoluer, l'améliorer, jusqu'à un certain point. Y'arrive un moment où il est plus sage de tout changer.
Pour reprendre mon analogie avec les smartphones: tu verrais MS aujourd'hui continuer d'essayer de mettre des rustines sur Windows Mobile 6 ??? Avoue quand-même c'était plus sage de laisser tomber et de repartir de zéro (même si ça sent la réaction motivée par l'urgence, et que le résultat prête à discussion…).

Et si C# était la panacée tout le monde l'emploierait, et on n'aurait rien inventé d'autres comme langages depuis. Hors t'as pas entendu parlé du F# ? Tiens un nouveau langage, et fait par MS en plus ! Etrangement là personne ici pour dire que ça sert à rien, que c'est pas fiable, que les perfs seront merdiques, …
Donc si MS fait un nouveau langage c'est obligatoirement génial, et si c'est Apple c'est nécessairement une daube signifiant la fin imminente de l'entreprise (la preuve serait déjà sur Twitter d'après certains ) ?

Swift étant un langage "sûr" il effectue des vérifications aux bords et une gestion automatique de la mémoire. Donc comme C#. Alors comment Apple fera t-il pour faire exactement les mêmes opérations mais en plus rapide ? Via un champ de distorsion de la réalité créé par le fantôme de Steve Jobs au sein de chaque processeur ?

Ça t'es pas venu à l'idée que pour faire une même chose, par exemple la gestion automatique de mémoire, il pouvait y avoir plusieurs méthodes ?
Tu prends ARC et un ramasse-miette à la Java, tu verras une sacré différence de perfs. Parce que si le but est le même, les deux ne s'y prennent pas du tout pareil. ARC rajoute les fonctions de libération de mémoire dans ton code au moment de la compilation de ton appli, ce qui n'a donc aucune incidence sur la vitesse d'exécution ensuite. Alors qu'un ramasse-miette c'est un processus qui va passer son temps à surveiller ton programme pendant qu'il tourne. Aussi bien foutu qu'il soit il sera toujours plus lent.

Et patience, tu verras fleurir sur le net d'ici quelques temps pas mal d'articles sur les "mystères" de Swift…

Pour toi je ne sais pas mais l'industrie apprécie en général de pouvoir doubler ses ventes.

Sauf que de ce que j'ai pu voir de nombreux témoignages de devs, Android en plus d'iOS ça ne double absolument pas tes revenus. Beaucoup de contraintes techniques avec un parc rempli d'appareils avec des OS obsolètes (en gros t'es souvent obliger de réinventer la roue parce qu'il manque ceci ou cela), un parc très (trop ?) diversifié qui rend compliqué de tester ton appli vu la pléthore de terminaux qu'il faut avoir. Et surtout un retour sur investissement plus que moindre: un parc important, mais, un piratage massif, nombre d'utilisateurs qui utilisent leurs smartphones comme un vulgaire téléphone et qui n'ajouterons jamais une appli de leur vie dessus, des fans intoxiqués par le discours démagogique du "tout gratuit" de Google et qui prennent pour une insulte la vue d'une application payante, … Avec ça dur de rattraper les utilisateurs iOS qui eux ne semblent pas victime d'évanouissement à la simple idée de mettre un euro ou deux dans une application.
Donc en fait tu ne double rien du tout. Bref tu tombes dans une idéologie simpliste qui se heurte à la réalité chiffrée…

[DonQuiche]

Tu vois pas en quoi un langage conçu il y'a plus de 20 ans et qui s'est alourdi en fonctionnalités et en instructions d'années en années pourrait être vieillissant.

Du concret s'il te plaît. Montre-moi ces fonctionnalités que Swift améliore.

Si MS refaisait C# aujourd'hui ils changeraient sans doute plusieurs choses. Mais Swift ne les améliore pas, c'est un langage conservateur. Il a sa place parce que la plateforme Apple impose le comptage de références et que le langage tourne autour de ça mais voilà tout, ce n'est pas un langage innovant. Il a l'air bien foutu et doté de fonctionnalités correctes mais ça s'arrête là.

Tu prends ARC et un ramasse-miette à la Java, tu verras une sacré différence de perfs.

Au moment où j'ai écrit le post que tu citais j'ignorais qu'ils avaient conservé le comptage de références puisqu'ils parlaient d'une gestion automatisée de la mémoire alors que le comptage de réfs n'est que semi-automatisé. Cela dit, non, tu ne verras pas cette sacrée différence de perfs.

ARC rajoute les fonctions de libération de mémoire dans ton code au moment de la compilation de ton appli, ce qui n'a donc aucune incidence sur la vitesse d'exécution ensuite.

Il est bien connu que de devoir ajouter une incrémentation atomique, une décrémentation atomique (environ 100ns chaque) et deux branchements conditionnels à chaque assignation d'une variable, en plus des 8 octets additionnels par instance, ça n'a aucune incidence à l'exécution.

Alors qu'un ramasse-miette c'est un processus qui va passer son temps à surveiller ton programme pendant qu'il tourne. Aussi bien foutu qu'il soit il sera toujours plus lent.

Je t'invite à te renseigner et tu verras que le consensus en la matière parmi ceux qui bossent sur ces sujets est qu'un GC mark-n-sweep est plus rapide et plus simple mais que le comptage de références a pour avantage une absence de pauses (latence maximum inférieure) et une plus faible consommation mémoire.

Sauf que de ce que j'ai pu voir de nombreux témoignages de devs, Android en plus d'iOS ça ne double absolument pas tes revenus.

Ok, ok, l'industrie est remplie d'abrutis qui perdent leur temps sur Android, vive iOS, iOS vaincra, gloire à Apple et loué soit Jobs.

[Le Vendangeur Masqué]

Renseignements pris, il semble qu'Apple a en fait conservé le modèle par comptage de références (ARC) et a donc ajouté des constructions spécifiques à ce dernier dans leur langage : explicitation des références fortes (accès aux membres forts par !. au lieu de .) et mot-clé weak pour déclarer des membres faibles. Cela semble être la seule spécificité du langage mais à elle seule elle justifie la création d'un nouveau langage pour s'adapter à ce mécanisme en vigueur partout au sein de la plateforme Apple. Je n'ai pas vu d'autre raison mais un fin connaisseur de la plateforme en verra peut-être.

En effet s'il y'a des spécificités, ça devient juste impossible de reprendre tel quel un autre langage. Swift s'appuie sur plein d'autres choses qu'utilise déjà Apple et je les vois pas sortir un C# ou un Java customisé. Ça aurait l'air franchement bizarre… Pas sûr qu'Oracle ou MS aurait pas râlé sur un Apple "dévoyant" leur beau langage.
D'ailleurs même sans ça je crois qu'il y aurait trop d'incertitude juridique pour la Pomme à employer C# ou Java. Sans ces deux là il restait quoi ? Des petits langages, donc une faible popularité, donc très peu connus de la majorité des devs. Autant dire que pour beaucoup c'était comme repartir de zéro.

Encore une fois je pense donc que ceux qui crient haut et fort que c'était une idée stupide n'ont visiblement rien compris aux tenants et aux aboutissants du sujet. Le troll il est là.

[Vlozer]

Le troll il est là.

Nan, le troll c'est quand t'as parlé de vieillissant C#...
Je veux dire, pour un mec qui dev sur MacOS c'est assez cocasse...
Je peux comprendre que certains soient emus de passer de l'ObjC à Swift au bout de tant d'années, mais gardez quand meme en tete qu'à l'echelle de la véritable informatique c'est juste anecdotique...

[Le Vendangeur Masqué]

Du concret s'il te plaît. Montre-moi ces fonctionnalités que Swift améliore.

Amusant qu'on me demande de justifier une bonne opinion, alors que d'autres ici ont fait de l'accusation à charge sans que personne n'aille leur demander la moindre justification.

Si MS refaisait C# aujourd'hui ils changeraient sans doute plusieurs choses.

Voilà pourquoi Apple préfère laisser tomber ObjC et passer à autre chose. Tout comme si toi tu trouves C# très bien, ça empêche pas pour autant MS de bosser sur F#. Des boîtes comme ça ne créent pas des nouveaux langages juste pour s'amuser.

Mais Swift ne les améliore pas, c'est un langage conservateur. Il a sa place parce que la plateforme Apple impose le comptage de références et que le langage tourne autour de ça mais voilà tout, ce n'est pas un langage innovant. Il a l'air bien foutu et doté de fonctionnalités correctes mais ça s'arrête là.

Comme l'a dit un gars de chez Apple: "on a fait un langage pour OS X et iOS". Donc oui ça correspond à leurs besoins, et ça a l'air bien foutu et relativement performant. C'est donc probablement pas une "révolution", mais ces 3 raisons justifie sans problème son existence.
Et comme ça a été rappelé on a jamais reproché à MS d'avoir pondu son langage… z'aurais pu utiliser Java, non ?

Au moment où j'ai écrit le post que tu citais j'ignorais qu'ils avaient conservé le comptage de références puisqu'ils parlaient d'une gestion automatisée de la mémoire alors que le comptage de réfs n'est que semi-automatisé. Cela dit, non, tu ne verras pas cette sacrée différence de perfs.

Une différence suffisante en tout cas pour qu'Apple qui s'était essayée à créer un ramasse-miette mette le projet à la corbeille et passe à ARC. N'oublions pas non plus qu'Apple est sur le marché des smartphones, domaine où gaspiller des ressources n'est pas une idée intéressante.

Il est bien connu que de devoir ajouter une incrémentation atomique, une décrémentation atomique (environ 100ns chaque) et deux branchements conditionnels à chaque assignation d'une variable, en plus des 8 octets additionnels par instance, ça n'a aucune incidence à l'exécution.
Je t'invite à te renseigner et tu verras que le consensus en la matière parmi ceux qui bossent sur ces sujets est qu'un GC mark-n-sweep est plus rapide et plus simple mais que le comptage de références a pour avantage une absence de pauses (latence maximum inférieure) et une plus faible consommation mémoire.

A propos des gens "qui bossent sur le sujet", moi je dirais que si le garbage collector c'était plus performant, Apple ne l'aurait pas laissé tombé.
Et je note ce que tu dis sur la faible latence et consommation de mémoire, là encore ça correspond pile-poil au marché mobile et ses contraintes particulières.

Ok, ok, l'industrie est remplie d'abrutis qui perdent leur temps sur Android, vive iOS, iOS vaincra, gloire à Apple et loué soit Jobs.

Des type qui sont tout content de vendre 1 ou 2 douzaines d'applis par mois j'appelle pas ça l'industrie. Sur Android y'a que les gros qui s'en sortent, le reste c'est beaucoup d'amateurs. Pareil quand ici je lis un article sur les "les héros du développement Windows Phone"… qui gagnent pas plus qu'un dév débutant dans une boîte.

Moi si tu veux je ne critique pas les idéalistes ou ceux qui programment pour s'amuser, chacun ses choix. Mais qu'on arrête de nous faire croire au Père Noël… Même récemment l'écart de rentabilité est toujours aussi impressionnant:
http://www.begeek.fr/google-play-vs-...e-google-99957

Y'a du téléchargement mais la monétisation suit pas. Ça n'est donc pas abruti d'y aller, mais par contre de dire que ça va doubler tes revenus, si.

[Le Vendangeur Masqué]

Nan, le troll c'est quand t'as parlé de vieillissant C#...

20 ans, surtout en informatique c'est une éternité. Apple a eu le courage de passer à autre chose, chez MS on continue encore de croire en la jeunesse éternelle.

Je veux dire, pour un mec qui dev sur MacOS c'est assez cocasse...

Bon enfin ça fait une bonne douzaine d'année que ça s'appelle OS X. Si tu veux démontrer que tu n'y connais rien c'est réussi. Sinon t'imagines le journaliste parlant du dernier MSDOS 8 avec des tuiles ? Il est aurait pas l'air con… Bref…

Et en quoi c'est cocasse ? On serait pro-immobilisme chez Apple ?
C'est un peu tout le contraire. La Pomme a jamais hésité à changer d'architecture, d'OS, d'API, de créer des plateformes, … et aujourd'hui de langage. Apple c'est vraiment pas la marque de ceux qui aiment le conservatisme et les vieux trucs.

Je peux comprendre que certains soient émus de passer de l'ObjC à Swift au bout de tant d'années, mais gardez quand meme en tete qu'à l'echelle de la véritable informatique c'est juste anecdotique...

Emus ? non j'ai pas vraiment noté ça. Par contre t'as des râleurs qui n'y connaissent rien, mais ça c'est comme d'hab. Quand à la "véritable informatique" tu nous parle de quoi ? Quand on voit que MS est devenu tout petit face à Google ou Apple (dont les seules ventes d'iPhone dépassent les bénéfices de tout Microsoft c'est dire…), j'ai un peu l'impression que tu en est resté à un temps depuis révolu. Comme tu dis, cocasse…