Discussion :

[Hinault Romaric]

WWDC : Apple dévoile son nouveau langage de programmation Swift
qui serait plus sûr, plus rapide et plus fiable qu’Objective-C

La conférence WWDC 2014 (Apple Worldwide Developers Conference), l’événement majeur de l’année regroupant les développeurs autour des technologies d’Apple a été riche en annonces pour sa première journée.

La plus grosse surprise du jour a été la présentation d’un nouveau langage de programmation par la firme à la pomme croquée pour le développement d’applications pour iOS et OS X.

Baptisé Swift, ce nouveau langage introduit une syntaxe toute nouvelle. Apple souhaite marquer la rupture avec le langage C, sous lequel repose Objective-C. Selon Craig Federighi, vice-président d’Apple, à qui l’honneur a été accordé pour annoncer le langage, « Swift représente le nouveau Objective-C sans le langage de programmation C ».

Swift sera inclus par défaut dans l’outil de développement Cocoa et Cocoa Touch. Il reposera, pour un début, sur le même runtime qu’Objective-C et le code écrit en Swift pourra cohabiter avec du code C/Objective-C, ceci pour éviter dans un premier temps de dépayser les développeurs déjà familiers avec C/Objective-C. Mais, le langage évoluera vers une syntaxe proche des langages de script comme Python.

Par rapport à Objective-C, Swift introduit de nouveaux opérateurs ; prend en charge les types de variables comme les Tuples et les types facultatifs ; les génériques ; « closures » ; des structures qui soutiennent des méthodes, des extensions et des protocoles ; des itérations rapides sur une plage ou une collection ; le support des modèles de programmation fonctionnelle, etc.

Swift bénéficiera d’une intégration parfaite avec Xcode. Les développeurs auront à leur disposition un éditeur de code interactif, permettant d’appliquer des changements dans le code et de voir instantanément les résultats sur l’application.

« Swift est un nouveau langage de programmation puissant pour OS X et iOS, qui permet aux développeurs de créer avec facilité des applications incroyables », vante Apple dans un communiqué de presse. « Swift aide les développeurs à écrire du code plus sûr et plus fiable, en éliminant les erreurs qui existent avec Objective-C. Les développeurs peuvent facilement intégrer Swift dans leurs applications existantes. »

Selon Apple, le langage a été conçu avec la sécurité à l’esprit, avec notamment les variables qui doivent être initialisées avant utilisation, des tableaux qui sont vérifiés en cas de débordement ou encore la gestion automatique de la mémoire. Apple met également en avant la vitesse du langage. Par exemple, un algorithme de tri complexe est 3,9 fois plus rapide que son équivalent en Python et également plus rapide que son équivalent en Objective-C.

Dès que les versions stables du prochain iOS et OS X seront disponibles, les développeurs pourront publier sur l’App Store leurs applications développées avec Swift.


Source : WWDC 2014


Et vous ?

Que pensez-vous de ce nouveau langage de programmation ? A-t-on encore besoin d'un nième langage ?

[abriotde]

Son principale défaut : tout comme Objective-C c'est un langage propriétaire exclusivement réservé au développement Apple. Cela limite grandement l’intérêt.
Sinon dans l'absolu un langage plus rapide a l’exécution et au développement est toujours le bienvenu. Je doute que le langage soit vraiment plus rapide car le benchmark est sur un algorithme répétitif simple que les VM compilent en langage machine pour les plus optimisé. La VM est simplement plus optimisé car plus récente...

[CP / M]

Son principale défaut : tout comme Objective-C c'est un langage propriétaire exclusivement réservé au développement Apple. Cela limite grandement l’intérêt.
Sinon dans l'absolu un langage plus rapide a l’exécution et au développement est toujours le bienvenu. Je doute que le langage soit vraiment plus rapide car le benchmark est sur un algorithme répétitif simple que les VM compilent en langage machine pour les plus optimisé. La VM est simplement plus optimisé car plus récente...

Objective-C n'est pas un langage propriétaire. Ce qui l'est, c'est l'implémentation par Apple des librairies Cocoa, NextStep et ce qui gravite autour, même si GNUStep est une réimplémentation partielle de NextStep. Et clang et gcc sont tout à fait apacbles de compiler de l'Objectve-C ; c'est d'ailleurs les compilateurs qui sont ou ont été fournis par Apple.

[Gugelhupf]

Est-ce que les programmes créés avec Swift seront exécutés par une machine virtuelle Apple ?

Objective-C n'est pas un langage propriétaire.

De base non. Mais Apple est la seule société à l'utiliser, et je vois mal un programme en Objective-C sans les API Cocoa etc...
Objective-C était un langage mort jusqu'à ce que les iPhone/iPad débarquent.
Le jour où Apple laissera tomber Objective-C, ce sera la fin de celui-ci.

[Sylvaner]

Objective-C était un langage mort jusqu'à ce que les iPhone/iPad débarquent.

Merci grâce à toi je comprend ce que j'ai ressenti quand j'ai appris ce langage, c'est donc un langage zombie

... même si GNUStep est une réimplémentation partielle de NextStep. Et clang et gcc sont tout à fait apacbles de compiler de l'Objectve-C ...

C'est officiel, le masochisme informatique existe.

[Le Vendangeur Masqué]

Beaucoup de développeurs iOS réagissent sur Twitter et pensent plutôt passer à Xamarin qui à l'avantage de cibler aussi Android et Windows phone.

L'homme qui a vu l'ours, qui a vu… LOL

Désolé mais la campagne de FUD ça ne prendra pas. Non Twitter n'est pas envahi de devs avec la bave aux lèvres…
Et franchement des rageux on en a chaque fois qu'Apple dévoile un truc qui sort de l'ordinaire. Tout ça parce que ça remet en cause la fainéantise et la médiocrité de certains pseudo développeurs. Minable et insignifiant mais on en a l'habitude…

Comparer avec Xamarin c'est juste n'importe quoi ! Sans parler des qualités propres de Swift face à un vieillissant C#, le critère des perfs disqualifie automatiquement ce bricolage lourd qu'est Xamarin.
Et vu la taille du marché d'Apple (un parc total qui frise le milliard d'appareils) et de ses clients qui n'ont pas de pingrerie à acheter des applis, je dois dire que l'argument du "ça tourne ailleurs" m'est parfaitement égal.

[rthomas]

Beaucoup de développeurs iOS réagissent sur Twitter et pensent plutôt passer à Xamarin qui à l'avantage de cibler aussi Android et Windows phone.

[iolco51]

Comme d'habitude Apple fait les chose différemment. D'habitude j'aime bien ceux qui font différemment, mais comme il y a déjà pléthore de langages...

A l'époque Objective-C était un langage pertinent pour les devs, au vu de la part de marché d'IOS jusqu'il y a 4-5 ans. Swift le sera-t-il autant? Et puis Objective-C avait quelques heures de vol (1983, c'est quand même du éprouvé sur long terme).

Maintenant, un langage de programmation juste pour IOS, alors que les parts de marché d'IOS sont en nette régression, et que les devs doivent déjà maitriser au grand minimum une demi douzaine de langages pour être performants.

C'est juste S.T.U.P.I.D.E.

Mini état des lieux du métier de développeur:

• Les langages répandus (C, C++, Haskell, Python, Perl, Objective-C, Java, Javascript, Scala, Groovy, Lisp et ses dérivés, Ruby, C#, F# et autres langages de .NET, PHP, Lua, langages de shell divers), sans oublier les dinosaures (FORTRAN, COBOL -aie) et les petits derniers prometteurs (D, dart, coffee, GO), les tentatives de langages plus ou moins propriétaires, les langages à applications spécifiques (VBA, R, Mathlab, les variantes de SQL), la multitude de ceux que j'ai oublié, et bien sur se tenir a jour des nouvelles versions et fonctions de tous ces langages. Combien de ces langages devez vous maitriser un minimum pour être performant dans votre métier?
• On ajoute les frameworks qu'il faut maitriser, les concepts de plus haut niveau (architecture SOA, MDA... Les concepts SOLID, injection de dependance, les design patterns), les methodes de dev (TDD, BDD, La rache), les methodes et process d'ingenierie (RUP, SCRUM, XP, Crystal, la rache), l'integration continue et DevOps...
• J'ai failli oublier les grandes bases: l'architecture systeme, les processeurs, la mémoire et sa gestion, les protocoles et les services réseau (OSI, TCP/IP, HTTP...etc.), les structures de données.
• Ah, et les formats de sérialisation données (XML, JSON, protocol buffers...), les protocoles de services (JMS, COM, CORBA...), les couches de présentation (HTML et consorts... Heureusement le HTML semble prendre la tête)
• N'oublions pas non plus les outils: IDEs, compilateurs, gestionnaires de version et consorts
• Et puis les bases de données, car il faut en savoir dessus (toutes les variantes SQL, Big Data, orientées graphe
• On rajoute aussi les bonne pratiques, la sécurité de l'information
• Enfin et surtout: savoir faire du code qui marche (et qui fait ce qu'il doit faire) dans les temps impartis

Wow!

Merci Apple. Nous avions justement besoin d'un nouveau langage, qui n'est pas interopérable, que vous êtes les seuls a développer et soutenir, avec une ÉNORME API, qu'il faudra (ré)apprendre, maitriser (et évidemment debugger pour vous, comme toute nouvelle techno informatique qui sera truffée de bugs mystérieux).
Et puis le communiqué est plutot rigolo:

• Gagner un pouillème sur les tris d'objets? C'est presque comique comme promotion de langage, sur du big data je comprendrais l’intérêt, mais sur un terminal mobile ou un PC Mac je n'ai pas vu de problème de perfs avec les tris depuis 15 ans dans 99% des cas d'utilisation. Et encore je doute de leur benchmark, lorsqu'on se rendra compte que peut-être trier un tableau d'entiers prend 15 fois plus de temps qu'en C/Java/Python/C#.
• Et communiquer sur la sécurité alors que le bousin va être en bêta dans les 5 années à venir avec une multitude de failles dans le coeur du langage (ou le compilateur, ou les API) bien plus faciles a exploiter en masse que les erreurs de dev.

COOL !

Ceci dit, que j'aime avant dans notre métier de développeur c'est que l'on ne s'ennuie jamais.

[Le Vendangeur Masqué]

Comme d'habitude Apple fait les chose différemment. D'habitude j'aime bien ceux qui font différemment, mais comme il y a déjà pléthore de langages...

Qu'il y ai beaucoup de langages existants est tout sauf un problème si Apple en sort un qui soit pertinent.

A l'époque Objective-C était un langage pertinent pour les devs, au vu de la part de marché d'IOS jusqu'il y a 4-5 ans. Swift le sera-t-il autant?

Ça ne veut strictement rien dire la PDM ! Comme je le disais en comptant iOS + OS X on parle d'un marché avec près d'un milliard d'utilisateurs (et très actifs). Y'a de quoi rentabiliser 2 à 3 semaines de formation à Swift. J'ai commencé de lire le bouquin d'Apple et franchement ça a l'air tout sauf compliqué.

Et puis Objective-C avait quelques heures de vol (1983, c'est quand même du éprouvé sur long terme).

Et ? Donc on ne doit rien inventer de neuf parce que ce qui existe est enfin arrivé à fonctionner à peu près. C'est réjouissant ta vision du progrès…

Maintenant, un langage de programmation juste pour IOS, alors que les parts de marché d'IOS sont en nette régression, et que les devs doivent déjà maitriser au grand minimum une demi douzaine de langages pour être performants.

1/ La PDM d'iOS est pas vraiment en régression. Parce que déjà elle est repartie à la hausse dans certains pays où elle avait baissé (phénomène évidement prévisible des déçus d'Android), qu'en plus Apple s'étend sur de nouveaux marchés géants (Inde, Chine, …), et surtout que les instituts qui font ses stats mélangent tout et n'importe quoi dans leurs chiffres. Comptabiliser une tablette jouet (!) ou bas de gamme de supermarché qui finira au bout de 15 jours dans un tiroir, ou un remplaçant de feature phone vendu à une mémé qui ne téléchargera jamais une app, tu crois que c'est sérieux ???
Regarde les chiffres de ventes d'applis et de consultation du Web: iOS est (très) largement devant ! Or le réel c'est bien la seule chose qui compte.
2/ T'as complètement zappé l'existence d'OS X, qui est loin d'être négligeable. Apple est bien l'un des seuls constructeurs à voir depuis des années sa part de marché progresser, crise ou pas. Et le Mac rapporte à la Pomme plus que les bénefs des 5 plus gros fabricants de PC réunis. Omettre le Mac de l'équation c'est donc pas très pertinemment et ça ne montre comme pour iOS que tu ne connais à peu rien du marché d'Apple et de ses devs.
3/ Est-on a l'abri d'un nouveau segment de produit Pommé sur lesquels les devs pourraient se ruer ? T'avais prévu le renouveau du Mac ? La sortie de l'iPhone et de l'iPad ?

C'est juste S.T.U.P.I.D.E.

Quoi donc ? Ton commentaire ?

Cette phrase on pourrait l'encadrer. Je l'ai entendu pour à peu près tout ce qu'a sorti Apple depuis 10 ans. Comme d'hab des gens dans leur petit confort, qui ne voient pas le monde changer, qui ne voient pas le potentiel du produit, …

Mini état des lieux du métier de développeur:

Rectification: Mini état des lieux du métier de développeur à oeillères:

Ta liste c'est sympa, mais elle est à l'image du marché de la téléphonie il y a 7 ans: des acteurs bien implantés mais avec des solutions dépassées (hier Nokia/Microsoft/RIM, aujourd'hui Java/C#), des petits nouveaux acteurs sans la moindre base de clients et donc qui ne perceront jamais (hier Palm, aujourd'hui Haskell, Groovy).
Et là pouf t'as Apple qui débarque: c'est pas des rigolos, le produit tient la route, et derrière y'a nombre de devs, de clients, et de fans (qui peuvent être des deux premières catégories). L'iPhone personne n'y croyait et pourtant ça a tout changé. Pour les devs un nouveau (bon) langage peut être la même révolution.

Nous avions justement besoin d'un nouveau langage, qui n'est pas interopérable, que vous êtes les seuls a développer et soutenir, avec une ÉNORME API, qu'il faudra (ré)apprendre, maitriser (et évidemment debugger pour vous, comme toute nouvelle techno informatique qui sera truffée de bugs mystérieux).

1/ Pas interropérable ? ObjC l'était fort moyennement (le langage oui mais pas Cocoa), et pourtant des millions de devs l'utilisent encore. Il vient d'ailleurs de fêter ses 20 ans…
2/ J'ai pas compris ton histoire d'énorme API: Cocoa garde les mêmes classes et méthodes que tu codes en ObjC ou en Swift. Donc y'a rien à rapprendre de ce côté là, or pour moi c'est le principal.
3/ L'histoire des bugs ça fait rire. Aucun langage n'aurait jamais décollé s'il fallait avoir peur d'y trouver un bug.

Et puis le communiqué est plutot rigolo:

• Gagner un pouillème sur les tris d'objets? C'est presque comique comme promotion de langage, sur du big data je comprendrais l’intérêt, mais sur un terminal mobile ou un PC Mac je n'ai pas vu de problème de perfs avec les tris depuis 15 ans dans 99% des cas d'utilisation. Et encore je doute de leur benchmark, lorsqu'on se rendra compte que peut-être trier un tableau d'entiers prend 15 fois plus de temps qu'en C/Java/Python/C#.

L'exemple du tri s'en était un parmi d'autres. L'idée c'est de trouver un bench pour montrer les perfs du langage par rapport à un autre. Que tu ne passes pas des journées à faire du tri, c'est bien possible, d'ailleurs moi non plus. Mais par contre les xx% de perfs en plus de ce langage, c'est critique dans le cas d'une appli mobile où les CPU sont encore très loin de ceux d'Intel sur PC. Chaque pour-cent gagné c'est en plus pour l'autonomie.

• Et communiquer sur la sécurité alors que le bousin va être en bêta dans les 5 années à venir avec une multitude de failles dans le coeur du langage (ou le compilateur, ou les API) bien plus faciles a exploiter en masse que les erreurs de dev.

COOL !

Encore perdu, comme déjà expliqué c'est les mêmes API, et c'est le même compilo LLVM. Donc on a vu (bien) pire…

Ceci dit, que j'aime avant dans notre métier de développeur c'est que l'on ne s'ennuie jamais.

Ouais bof, y'a d'autres plaisirs moins malsain que de ce moquer de ceux qui font quelque chose.

[teddyFry]

J'ai du mal à comprendre comment avec le même runtime un language peut tourner deux fois plus vite qu'avec un autre.
Il me semble que traduire un programme de C# à F# n'apporte pas de bénéfices particuliers à moins d'utiliser les nouveaux concepts introduits avec le F#.

Enfin il me semble que faire évoluer l'objectif C aurait été un choix bien plus judicieux pour leur écosystème.

[DonQuiche]

Il était temps de flinguer Objective-C, ils auraient dû faire ça il y a dix ans. Du coup je consentirai peut-être à m'intéresser à cette plateforme. Par contre je passe sur les grands élans à propos de la révolution, du top de la recherche, des performances incroyables, etc : avec Apple on a l'habitude des superlatifs, promesses faramineuses, graphiques sortis du chapeau et de la com' outrancière. A priori c'est un langage à l'approche standard (impératif et objet à typage statique) avec des fonctionnalités standard en 2014 (éléments de prog fonctionnelle, cf. Scala, C#, Java et tous les autres) et point barre. Et encore : rien pour les traitements concurrents en 2014 ? Mouaiiiiis.


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 ?

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

[TheLastShot]

Au début quand j'ai lu cette nouvelle j'ai réagi un peu de la même manière que mes prédécesseurs ("Allez, Apple continue de se la jouer Hipster et on va encore avoir droit à un langage dégueulasse"). Mais finalement, après avoir jeté un coup d'oeil (rapide) au langage en question, je dois avouer que c'est plutôt une bonne chose. En effet, Apple a fait le choix de s'orienter sur un autre paradigme, à savoir le paradigme fonctionnel qui certes est un peu difficile à comprendre pour les non initié mais qui au final permet d'avoir un code beaucoup plus propre (quand on sait s'en servir) que ce que donnait l'Objective-C (faut dire que c'était pas très difficile de faire mieux).

Alors certes ça rendra le travail un peu plus compliqué dans un premier temps pour ceux qui devront découvrir ce paradigme, mais au final ce sera peut-être un gain de temps sur le long terme. A voir...

[Bono_BX]

Et franchement des rageux on en a chaque fois qu'Apple dévoile un truc qui sort de l'ordinaire. Tout ça parce que ça remet en cause la fainéantise et la médiocrité de certains pseudo développeurs. Minable et insignifiant mais on en a l'habitude…

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

un vieillissant C#

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 !

le critère des perfs disqualifie automatiquement ce bricolage lourd qu'est Xamarin

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.

Et vu la taille du marché d'Apple (un parc total qui frise le milliard d'appareils) et de ses clients qui n'ont pas de pingrerie à acheter des applis

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

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.

[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

[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)

[Iradrille]

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)

Ça reste possible en C#.

Code C# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
struct withInt1 { }
struct withInt2 { }
 
class Foo {
	public int addNumber(int value1, int value2, withInt1 useless) { return value1 + value2; }
	public int addNumber(int value1, int value2, withInt2 useless) { return value1 * value2; }
}
 
var f = new Foo();
f.addNumber(1, 1, withInt1());
f.addNumber(1, 1, withInt2());

[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

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

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