Discussion :

[air-dex]

Par exemple, un algorithme de tri complexe est 3,9 fois plus rapide que son équivalent en Python

Les joies de la communication, où l'on compare un langage compilé optimisé pour une plateforme à un langage de script multi-plateformes. Je ne dis pas (ni ne pense) que Python est tout sauf performant, mais là c'est juste trop facile. Il eut été plus pertinent de comparer Swift à C++ ou C# qui sont bien plus proches.

A-t-on encore besoin d'un nième langage ?

Non. Mais là c'est Apple et comme d'habitude ils n'ont pas pu s'empêcher de faire du non standard.

[Abawell]

Moi je dis, enfin ! Apple se débarrasse de l'héritage de C dans Objective C.
Microsoft s'était inspiré des évolutions des langages existants à l'époque, comme C, Objective C et surtout java pour son C# et a fait un très bon travail. Aujourd'hui Apple fait la même chose en s'inspirant de C#, mais aussi de javascript et de Python.
Non il ne pouvait pas réutiliser un autre langage. Le langage est compilé en code machine et non pas en code proprio et doit resté compatible avec ce qu'offrait Objective-C en terme de langage objet.
Je ne vois pas en quoi il est plus propriétaire que les autres langages. Il l'est infiniment moins que C# ou java qui ont besoin d'une machine virtuelle. Il est indépendant de l'environnement et compilé en code natif avec LLVM qui existe sous d'autres plateformes. Il faudra juste attendre un peu et on verra peut être d'autres débouchés. Ce qui est propriétaire ce sont évidement les classes Cocoa de MacOS et iOS, mais rien à voir avec Swift.
Il est déjà annoncé que le terminal du Mac sera capable d'exécuter des commandes en Swift
L'équipe d'Apple a fait du beau boulot je trouve. J'ai lu la documentation et le langage présente de réelles avancées sur plusieurs points.

[DonQuiche]

Non il ne pouvait pas réutiliser un autre langage. Le langage est compilé en code machine et non pas en code proprio

Rien n'empêche de faire ça avec Java ou C# : à fonctionnalités égales c'est un simple choix de mise en œuvre (implémentation).

Il l'est infiniment moins que C# ou java qui ont besoin d'une machine virtuelle.

C# n'utilise pas de machine virtuelle (même si tout ça est surtout une question de sémiotique) et, encore une fois, ce sont là des détails de la mise en œuvre. Puisque Swift expose les mêmes fonctionnalités que Java ou C# il n'a aucun avantage intrinsèque sur eux. Aujourd'hui le code C# est par exemple compilé en natif avant d'être distribué sur Windows Phone.

et doit resté compatible avec ce qu'offrait Objective-C en terme de langage objet.

Là aussi rien n'empêche d'accomplir ceci, à moins qu'il n'ait fallu ajouter au langage des constructions spécifiques. Si oui je suis authentiquement curieux de savoir lesquelles.

Mon intérêt est justement de découvrir s'il y a une vraie raison technique derrière ce langage, spécifique à la compatibilité avec Objective-C et qui justifierait de ne pas utiliser un langage existant. Pour l'instant personne n'a pu m'instruire à ce sujet.

L'équipe d'Apple a fait du beau boulot je trouve. J'ai lu la documentation et le langage présente de réelles avancées sur plusieurs points.

Je reconnais que ça a l'air propre et bien carré.

[DonQuiche]

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.

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

[Abawell]

Là aussi rien n'empêche d'accomplir ceci, à moins qu'il n'ait fallu ajouter au langage des constructions spécifiques. Si oui je suis authentiquement curieux de savoir lesquelles.

Exemple:
En Objective C, une méthode peut s'appeler myMethodWithA:andB:

La déclaration s'écrit
-(void)myMethodWithA:(int)a andB:(int)b;

l'appel s'écrit
[myObject myMethodWithA:12 andB:42];

va écrire ça en C# pour rester compatible avec les librairies Cocoa en sachant que c'est plus qu'une question de compilation parce que le compilateur ne se contente pas de trouver l'adresse d'une méthode à appeler mais c'est réellement un message qui s'appelle myMethodWithA:andB qui passe plusieurs classes, le message pouvant être intercepté par des classes créées dynamiquement.

En Swift, pour répondre à ce problème Apple a créé la notion de nom de variable interne et externe.
La méthode est déclarée
function myMethodWithA( parA:Int, andB parB:Int);

andB est le nom externe du paramètre et parB le nom interne du paramètre à la fonction.

L'appel de la fonction s'écrit alors
myObject.myMethodWithA(12, andB:42);

Par défaut, le premier paramètre n'a pas de nom externe (mais peut en avoir un) et s'il n'y a pas de nom externe déclaré aux paramètres suivants, le compilateur utilise le nom interne (mais on peut lui demander de ne pas en utiliser).

Et ça ce n'est qu'un des nombreux points qui a obligé Apple a écrire un nouveau langage.

[DonQuiche]

va écrire ça en C# pour rester compatible avec les librairies Cocoa en sachant que c'est plus qu'une question de compilation parce que le compilateur ne se contente pas de trouver l'adresse d'une méthode à appeler mais c'est réellement un message qui s'appelle myMethodWithA:andB qui passe plusieurs classes, le message pouvant être intercepté par des classes créées dynamiquement.

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

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

[Hinault Romaric]

Swift atteint sa version 1.0
les applications développées avec le langage peuvent être publiées sur l’App Store

Swift a atteint sa version 1.0 et les applications qui ont été développées avec le langage de programmation peuvent désormais être soumises sur l’App Store.

Pour rappel, Swift est un nouveau langage de programmation qui avait été dévoilé par Apple en juin dernier, lors de son évènement WWDC 2014 (Worldwide Developers Conference). Ce nouveau langage marque la rupture avec C (sur lequel repose Objective-C) en introduisant une nouvelle 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, les « closures », les structures qui supportent des méthodes, les extensions et les protocoles, les itérations rapides sur une plage ou une collection, le support des modèles de programmation fonctionnelle, etc.

Swift GM est disponible avec Xcode 6 GM et peut être utilisé pour créer tout ou partie des applications pour iOS 8 et iOS 7. Le code écrit en Swift peut cohabiter avec du code C/Objective-C. Xcode 6 dispose d’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 passe en GM uniquement sur iOS. Les développeurs OS X devront encore se contenter de la bêta de Xcode 6.1 pour développer leurs applications qui ne peuvent pas encore être soumises sur le Mac App Store. Swift pour OS X passera en version GM lors de la sortie de la version stable de d’OS X Yosemite avec son kit de développement cet automne.

Télécharger Xcode 6 GM


Source : Apple


Et vous ?

Avez-vous testé Swift ? Que pensez-vous du langage de programmation ?

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

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

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

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

[Invité]

Pour rappel :

Objective-C ne se limite pas à Apple, même si certains diront que ce langage sans les API Apple n'a que peu d’intérêt.

Il faut savoir que Mac OS X n'est qu'une version modernisée de Next Step et qu'il est donc possible (même si ce n'est pas évident) de développer une application Objective-C sous Openstep et de la compiler sous Mac Os X.

[Olfredos6]

Un langage que pour leur plateformes, ça ne promet aucun succès sur les autres. Et qu'on me dise ce que Swift apporte que les autres actuels langages multi-plateformes n'ont pas. Vitesse d'exécution??? Aucun dev n'y croira

[epsilon68]

Hello,

J'aime bien objective c(++), justement il apportait la couche objet au c(++), tout en gardant la rapidité du c(++) du coup, toute mes librairies c et c++ marchait parfaitement (sqlite etc).

Quand j'ai vu swift, je me suis dit "NOOOON", puis j'ai quand meme lu les docs.
A première vue, je n'aimais pas trop la syntaxe, mais apres coup, elle fait du sense et je peux comprendre les decisions du design. Ce qui est top, c'est la l'interopabilité entre objective c et swift.

mais la plus grande avancé à mon avis, c'est de pouvoir visualiser le résultat dans xcode designer.
Parce que concretement, punaise ca manquait les composants dans xcode, avec aussi un peu d'interactivité.
Je pense que swift permettra de mieux developer les composants graphiques, et pour apple d'avoir une solution pour en proposer.

voila, donc je ne me precipite pas, j'attends de voir, mais je le suis de pres et je l'utiliserais sir je dois faire un composant graphique.

[Cyrilange]

Apple continue sa politique de la "cage dorée". Rien de ce qui est dedans ne peut sortir. Alors que tout devient de plus en plus "open" (même Microsoft) eux ils continuent de croire qu'ils peuvent fonctionner en restant hermétique. Ils sont en train de se tirer une balle dans le pied ! Ils seront bientôt seul sur une île déserte.

[epsilon68]

Comme si microsoft etait ouvert avec son .NET...
Je pense qu'Apple fait bien de tout controler, c'est de la que vient l'innovation.
Ils ont fait webkit, ils ont fait clang et maintenant c'est la suite logique...

[sekaijin]

Bonjour
Comme toi je ne vois pas en quoi Objective-C ou Swift sont plus fermés que C#

à ces débuts C# était on ne peut plus proprio il n'existait que dans les outils Microsoft

Objective-C est lui né dans une université et a été essentiellement implémenté par NexT. Le succès de NexT ayant été marginal, il n'y a eu que peu de travaux faits par la communauté.

Pour C# c'est le contraire Microsoft l'a fait pour lui et c'est la communauté qui l'a implémenté ailleurs. Lui donnant le dynamisme qu'on lui connait aujourd'hui.

Je ne vois pas en quoi Swift diffère. Le langage est ouvert à tous vous pouvez écrire votre compilateur comme Mono l'a fait pour C#
L’avenir nous dira si cette ouverture se crée, mais franchement lorsque C# est né la question de son adoption se posait réellement. Pour une entreprise investir de C# était synonyme de faire une croix sur les Unices, tous les systèmes embarqués et les Mac. Swift est aujourd'hui dans la même position.

Quant à la suite logique des propositions d'Apple dans le domaine cela ne date pas d'hier

Code swift :

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

1
2
3
4
5
6
7
func configureLabels(labels: UILabel[]) {
  let labelTextColor = UIColor.greenColor()
  for label in labels {
    // label inferred to be UILabel
    label.textColor = labelTextColor
  }
}

compaé a un autre langage auquel Apple à participé et qu'il a proposé sur ses plateformes en 1992

Code dylan :

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

1
2
3
4
5
6
7
let radius = 5;
let circumference = 2 * $pi * radius;
if (circumference > 42)
  format-out("Hello, big circle! c is %=", circumference);
else
  format-out("Hello, circle! c is %=", circumference);
end if

Swift ne sort pas du chapeau d'Apple comme ça. Il est le résultat de plusieurs décennies de travail sur les langages.

Si on regarde l'histoire une fois passé les balbutiements on a une situation très tranchée d'un coté des langages interprétés souvent très souples et permissifs, mais aussi très dynamiques et fonctionnels et de l'autre des langages compilés généralement très rigides, fortement typés peu dynamiques.
Bien sûr le monde est assez bigarré pour introduire beaucoup de nuances, mais il fut un temps où cette démarcation était très nette.

Plus on avance plus on voit les deux approche emprunter à l'autre les langages dynamiques piochent des structures la compilation et pas mal d'autres points. pendant que les langages dits structurés ajoutent du dynamisme du fonctionnel de l'introspection, etc.

C# et Objective C sont deux évolutions du C qui vont dans ce sens.

Dylan est né en 1990 chez Apple d'une évolution de LISP (Common Lisp Object System). Le besoin avoir un langage riche pour des appareils de faible capacité. La définition de Dylan (forme du langage) est venue de l'entrée de Microsoft et Carnegie Mellon University dans l'affaire.
le but est alors "Dylan is a multi-paradigm programming language that includes support for functional and object-oriented programming, and is dynamic and reflective while providing a programming model designed to support efficient machine code generation, including fine-grained control over dynamic and static behaviors." (il fut implémenté pour les Newton, premier PDA sorti en 1992)

On voit dans cet intitulé que SWIFT suit exactement le même but dans le même contexte (PDA Smartphone). La différence est qu'en 24 ans la théorie des langages à évoluée, les techniques de compilation aussi.

SWIFT est donc le résultat de 20 de travail universitaire tout autant que de la part d'Apple, mais aussi d'autre entreprise.
La question qui se pose aujourd'hui est

Apple saura-t-elle faire sortir SWIFT de son giron pour le généraliser ou le laissera-t-elle dans un univers fermé comme a pu l'être ApplTalk ?

On sait qui si l'entreprise ne fait pas d'effort pour généraliser une techno celle-ci reste marginale. Rare sont les cas ou une techno c'est généralisé alors que sont créateur bloquais sa diffusion.
Mais on sait aussi que proposer n'est pas suffisant. Chez Apple on doit se souvenir de Uniform Type identifier, qui fut proposé à la communauté, aux instances gérant les normes internet et qui n'a jamais décollé. C’était pourtant simple efficace et peu couteux. Mais Apple n'a fait que le proposer sans mettre le paquet pour le promouvoir.

A+JYT