Swift, un langage conçu par Apple pour Apple
Avec la nouvelle interface d’OS X Yosemite, les extensions d’iOS 8 et la « continuité » liant les deux, on en oublierait presque qu’Apple a présenté rien de moins qu’un nouveau langage de programmation. Swift, c’est son nom, est présenté comme « un Objective-C sans le barda du C ». Et il y a de ça.
Que les choses soient claires, Swift n’a pas été conçu comme un langage de programmation « universel » : il a clairement été conçu « pour le développement sur OS X et iOS », « pour Cocoa et Cocoa Touch ». Il repose sur la base du C et de l’Objective-C, « sans la contrainte de la compatibilité avec le C », mais avec toutes les technologies développées par les ingénieurs Apple ces dernières années (dont ARC et LLVM).
Swift se veut « moderne, sûr, interactif et performant ». Moderne, il l’est par sa syntaxe concise : oubliés les headers, envolés les points-virgules, Swift rappelle immanquablement les langages de script — Apple ne se lasse d’ailleurs pas de le comparer avec Python. Le simple exemple du « Hello world » est parlant. Ce code Objective-C :
#import <stdio.h>
#import <Foundation/Foundation.h>
int main(void)
{
NSLog(@"Hello, world!\n");
return 0;
}
Est équivalent à ce code Swift :
println("Hello world!")
La déduction du typage, l’interpolation de variables, les clôtures, les tuples et bien d’autres fonctions participent à cet allégement de la syntaxe du Swift. Il est incontestablement élégant, même si la concision va souvent de pair avec une certaine opacité. Apple fournit cependant une épaisse documentation d’une clarté exemplaire qui permettra aux développeurs de rapidement comprendre les particularités de Swift.
Apple assure avoir « des objectifs très ambitieux » pour Swift, en allant jusqu’à évoquer un système d’exploitation qui serait codé en Swift. Reste que pour le moment, il est d’abord et avant tout conçu pour développer des applications simples, ou les pans les plus simples d’une application.
Mais dans le même temps, l’idée est qu’il puisse se substituer de plus en plus à l’Objective-C et au C : le C sera toujours utilisé pour coder au plus près du matériel, mais il n’y a aucune raison de ne pas utiliser Swift pour le reste. Il peut donc déjà exploiter toute la richesse de Cocoa et Cocoa Touch, et il ne serait pas étonnant que les futures APIs d’OS X et iOS lui soient réservées.
LLVM a été particulièrement travaillé pour optimiser au mieux le code natif ARM ou x86-64 produit par la compilation d’un projet Swift — mais comme tous les autres langages « modernes », c’est sa syntaxe même qui assure que le développeur ne commette pas certaines erreurs communes ou tombe dans des pièges. Facilité d’appréhension du code et rapidité d’exécution vont main dans la main, alors qu’elles ont traditionnellement tendance à s’opposer.
Mais un des aspects les plus intéressants et les plus importants de Swift est sans doute son interactivité, qui rappelle celle des grandes heures du Lisp. En mode playground, le code Swift est compilé à la volée pour procurer un retour instantané au développeur — quelque chose de « normal » pour les développeurs web, et dont l’implémentation rappelle les travaux de l’ancien ingénieur d’Apple Bret Victor.
Cette fonction est extrêmement utile dans l’apprentissage du Swift, tout autant pour le développeur chevronné que le développeur débutant. Apple s’offre là l’occasion d’attirer de nouveaux publics à la programmation, donc de renforcer son écosystème. Et de le renforcer à long terme, puisque les développeurs Swift seront avant tout des développeurs OS X et iOS. Un langage conçu par Apple pour Apple, en somme.
GitHub regorge déjà de projets développés en Swift. Notre développeur Nyx0uf s’est fait la main sur ce langage avec son éditeur de texte mimant les fonctions de Writer Pro : vous pouvez télécharger la version Objective-C ici, et la version Swift là, de quoi comparer les deux.
La littérature informatique disent le contraire
Code explicite et simple = le développeur se concentre sur l'algorithme et d'être efficace. Le compilateur prend en charge nombre de choses implicites.
Swift fait effectivement l'impasse sur des choses fastidieuses que Obj-C demandait de faire (par exemple, swift reconnait bien que " " est une chaine et vous créé son instance, pas besoin de le dire explicitement, @ était déjà une macro pour initialiser une NSString..)
Swift ne demande pas que le premier paramètre d'une méthode soit nommé (il l'est implicitement par le nom des méthodes Cocoa pratiquement toujours)
Swift ne demande plus un ; à la fin d'une ligne (ça va, le compilo pige tout seul qu'on a fini son instruction, merci)
Swift fait utiliser une
etc.
LLVM permet d'optimiser le code et le préparer au delà d'un compilateur classique.
Et c'est du typage fort avec inférence de type a priori
@Mithrandir
Et c'est du typage fort avec inférence de type a priori
Cool un gars qui a commencé a se pencher sur le berceau du bébé, n'hésites pas à faire des retours.
@Mithrandir
OK
Juste pour vous faire une idée de la "puissance" de Swift (je ne sais pas si c'est le terme approprié) un développeur vient de publier un clone de flappy bird entièrement écrit en swift, et surtout en moins de 24 heures. Ça veut donc dire que le développeur a appris à coder en Swift et a eu le temps d'écrire le jeu pendant ce très court laps de temps.
Plus d'infos ici:
http://9to5mac.com/2014/06/03/apples-new-dev-language-swift-used-to-recreate-flappy-bird-in-less-than-24-hours/
PS: Ok c'est mon dernier lien vers un article de 9to5, promis.
Je n'y connais rien en code mais ce nouveau langage ne serait il pas la première brique pour faire tourner OSX sur des processeurs ARM made by Apple ? et dans un très long terme se passer d'intel.
non. et pour une bonne raison. C'est DEJA fait :)
LLVM/Clang (et l'usage de objective-C) fut la PREMIERE brique pour faire tourner Os X sur ARM depuis 2007 (et + évidemment en développement)
IOS = OS X + COCOA TOUCH (moins Finder etc) = noyau MACH+BSD (XNU) + tout le bazar = LA MEME FONDATION.
Si iOS tourne sur ARM cela signifie que le NOYAU de OS X (et toutes les couches systèmes supérieurs : io/kit, cups, bsd, xnu, runtime objective-C, la libC, launchd, etc etc etc) TOURNENT SUR ARM.
Il manquerait quoi ? une version ARM du finder ? une version arm de itunes ? ce genre là d'outils ? une version ARM de Quartz fenêtré ?
il est quasi évident qu'Apple a maintenu, au moins en version expérimentale, tout cela compilable sur ARM. Tout comme Os X existait pour intel des années avant l'annonce de mac intel.
On le savais MOR-DI-CUS parce que quand Apple acheta NeXT, ils avaient acheté (entre autre) la version INTEL 486 de NeXTStep : l'ancêtre de Os X.
NeXTstep était écrit dés l'origine (c'était l'un des buts du micro-noyau Mach) pour être portable. D'ailleurs, à l'origine, quand NeXT vendait des ordinateurs, NeXTstep tournait sur processeur motorola 68x00 (comme Mac Os donc...) avant de cesser leur vente et de vendre une version pour PC (intel 486) de NeXtstep (et une déclinaison sans noyau pour Solaris et autre unix, nommée Openstep). Bref NeXTstep était portable.
Apple porta Nextstep au PowerPC. Os X Server 1.0 était NeXTstep vite maquillé, Os X 10.0 était une fusion de Nextstep + quicktime + l'api de Os 9 (carbon) le tout en couleur fluo+transparence (tiens donc...).
et.. parce qu'on est jamais assez prudent, Apple continua à maintenir les évolutions de leur achat en version intel (pentioum, icoure duo, etc) jusqu'au jour où "subitement" Apple sortit Os X Intel. En disant "en fait Os X menait une double vie, huhuhu"
DONC
La même logique s'applique à Os X ARM : IOS existe, il tient dans la main :)
L'existence MEME de IOS vous ga-ran-tit qu'Apple a une version quasi totale (ou ptet totale après tout, au cas où...) de Os X ARM. c'est la même chose, la même base, la même fondation, c'est même parfois la même VERSION des noyaux/libs entre les deux "os".
Une entreprise prévoyante comme Apple a certainement, tranquillement, maintenue des versions fonctionnelles sous ARM des principales parties de l'interface graphique de os x (Finder et consorts), au cas où et pour prototypes.
C'est pour cela qu'on imagine facilement, que "subitement", Apple annonce des Mac ARM, avec un Os X sorti de sous le coude, "pouf" ! Apple en a la possibilité.
@oomu,
Dans les portages de NeXT Step tu oublis celui sur RS6000 IBM.
NeXT Step a tourné sur les trois architectures historiques du Mac : 68k, i86, POWER (Dont découle PowerPC)
Il me semble même qu'il y eu un portage sur SPARCen prémisse d'OpenStep
Pour ceux qui s'interroge sur pourquoi les informaticiens inventent tout le temps plein de langage, y a du sens à tout:
Comme 3/4 des trucs qu'utilise Apple, objective-C n'est pas réservé qu'à Apple, mais est antérieur à son usage par Apple et même par NeXT. Bien sur en pratique, seul Apple fournit un écosystème et support entier autour de Objective-C. Mais c'est juste un choix que d'autres entreprises ne font pas.
-
Origine:
Objective-C est à l'origine la création d'une entreprise (stepstone) puis repris sous licence par NeXT, puis ajouté à Gnu CC (mais le runtime obj-c restait sous licence propriétaire)
Le langage est compilable par GNU CC (pas propriétaire donc) et était normalisé au sein de OpenStep (l'ancêtre de Cocoa ) entre Sun et NeXT (et chais plus qui). Par la suite Sun se désintéressa de Openstep pour développer JAVA et sa fameuse Machine Virtuelle (la JVM).
De nos jours l'usage de gcc pour compiler du objective-C est supplanté par LLVM/Clang.
Le projet GNU créa sa propre version du runtime objective-C (donc sous licence GPL : libre).
Quand Apple acheta NeXT, le runtime objective-C de NeXT passa en licence opensource.
et puis Apple contribua (sous licence BSD : ouverte) à LLVM/Clang. Vers Os X 10.5, Apple utilisa un nouveau runtime objc-C. Sauf si je confonds avec l'ancien mais je ne pense pas, le nouveau est sous licence APL (opensource et considérée libre)
http://opensource.apple.com/source/objc4/objc4-551.1/
-
Objective C existe hors de Os X.
GNUSTEP:
Au début du développement de KDE et Gnome comme interface graphique pour Linux, un groupe de gens ont lancé le projet GNUStep, dans le but de porter le cadre de développement OpenStep et l'interface graphique de NeXTstep à Linux.
GNUstep (http://gnustep.org) est écrit évidemment en Objective C (et les réalités de l'ampleur délirante du projet et le manque de contributions font qu'ils ont aussi accepté des bibliothèques en d'autres langages). Gnustep est un projet libre, objective-c n'est pas contrôlé par Apple, et le projet ne doit rien à apple. Même l'usage de la normalisation OpenStep est libre. (par contre se déclarer Conforme à Openstep ne doit pas l'être je suppose).
Cocoa s'est progressivement éloigné d'Openstep, et GNUstep devenait obsolète: réussir à suivre les évolutions de cocoa était rajouter une énième mission impossible. Mais il y a 15 ans, l'idée était belle. Je pense encore que cela aurait été une meilleure fondation pour linux que GTK/Gnome ou QT/Kde. Mais les rendez vous ratés, les aléas des projets lancés par ci par là dans le monde pour enrichir en urgence le naissant linux ont fait que ça n'a pas pris sauce.
BREF: Objective-C n'est pas "propriété" d'Apple, ni fermé, ni exclusif. Le runtime c'est une autre histoire, mais il en existe plusieurs.
-
objective-C allait de paire avec les pensées autour de smalltalk, de la programmation objet, de la notion de "message", etc des années 80s.
Le runtime objective-C intègre nombre de bonnes pratiques et la brique essentielle à la puissance de objective-C.
La compatibilité de objective-C avec C (contrairement à C++) est un des enjeux majeurs du runtime obj-c : on peut lier du code compilé obj-c avec du code compilé C.
-
Cocoa et objective-C vont naturellement ensemble. L'expressivité de objective-C est utilisée à mort pour cocoa.
Cocoa repose sur des principes forts comme le paradigme MVC : modèle vue contrôleur et évidemment la programmation object, 2 concepts poussés en avant y a bien 20/30 ans.
Il y a donc un sens à pourquoi Objective C existe (comme pour perl, ou C, ou ruby d'ailleurs et bien sur python) et encore plus pour Openstep/Cocoa : le paradigme MVC.
Interface builder / Project Builder (les ancètres de Xcode, fournis avec Nextstep et les premières versions de Os X) mettaient en oeuvre MVC du début jusqu'à la fin.
y a donc une FORTE cohérence entre objective-C / le runtime objective-C / xcode / cocoa. Il serait difficile de supprimer l'un sans casser le reste.
Swift d'ailleurs reprends donc tout ce qu'il faut de Objective-C pour continuer la mise en oeuvre des idées de cocoa/xcode (et swift utilise le runtime objective-C à ce qui a été dit, ça garantit la compatibilité avec du code objective-C : un développeur peut utiliser swift au sein de son projet sans devoir jeter tout le reste à la poub.. corbeille)
@oomu
Très bon historique d'Objective C, avec pour moi une petit larme au moment de l'évocation de smalltalk ;-)
Adele Goldberg est une des figures de mon panthéon.
Pour ceux qui aime les "histoires", la lecture de the Design and Evolution of C++ de Bjarne Stroustrup, est pour moi à recommander. C'est une plongé dans des enjeux rarement aussi bien exposés.
Alan Kay et Avie Tevanian sont aussi des figures de mon panthéon.
Tiens, dès que j'ai vu cette ligne : println("Hello world!\n")
j'ai tout de suite pensé à ... Processing (processing.org)
On écrit exactement la même chose (dans cet exemple) pour le même résultat...
Et alors ?
Et alors quoi ? ;)
@poulpe63
Alors quoi ?
je me demande juste où tu veux en venir et ce que signifie pour toi le constat que tu fais ? ;-)
Des adeptes de mathematica ? :p Il a l'air pas très utilisé ce langage, enfin c'est que pour du calcul formel et des algorithmes.
@r0m135
Il est utilisé dans Mathematica :-)
Mathematica est un logiciel intégrant un langage,
comme Matlab, Scilab, Mapple ...
Est-ce que vous pensez que les apps écrites en Swift seront plus légères (du fait que leur code est plus léger) ou ça n'aura absolument aucun impact ?
Plus légère en poids ? En ressources ?
Ce n'est pas parce que ton code haut niveau est de complexité faible que le code compilé va être simple. Il y a des choses que tu peux écrire en 1 ligne dans un langage et en 10 dans un autre. Et tu ne peux pas dire qui va être le plus rapide juste comme ca.
Par contre, au niveau developpement il y a des choses interessantes, une moindre complexité du code donc une meilleure facilité a maintenir et a developer.
Perso, n'ayant appris que le C et l'assembleur pour programmer des micro-contrôlleurs, ce nouveau langage très simplifier m'inciterait plus à me mettre à la programmation pour une App OS X ou iOS qu'avec l'objective-C. J'ai essayé d'apprendre l'objective-C seul : j'ai vite laissé tombé à cause de sa complexité...
Simplifier un langage, c'est bien. Savoir l'optimiser, c'est mieux. Savoir l'utiliser comme un orfèvre utilise l'or, c'est tout l'art du programmeur...:
@jujuv71 :
Swift ne sera pas forcément plus "simple" qu'Objective-C, même si la syntaxe est plus légère.
Les designs patterns de Cocoa sont toujours là. Les frameworks ne changent pas.
Le langage lui-même utilise les Generics, les closures, pattern matching, etc. Tous des concepts qui ne sont pas forcément triviaux.
Swift semble aller assez loin pour limiter les erreurs de programmation (break automatique dans les switch, typage par inférence, gestion simplifiée pour éviter les retain cycles,...), ce qui est une très bonne chose.
Après un premier tour, je dirais que Swift est une remise à neuf, pour repartir sur des bases neuves et solides, sans trainer trop d'historique.
Mais pas forcément un langage simple et facile d'accès à des années lumières d'Objective-C.
Aujourd'hui Swift est tout jeune et donc pour le moment réservé à ce pour quoi il a été conçu par son créateur (Apple), c'est à dire le développement OS X et iOS.
Cependant, je ne serais pas étonné si, à plus ou moins moyen/long terme, il soit utilisé sur d'autres plateformes. Ce n'est qu'un langage de programmation, et de ce fait il est parfaitement possible d'écrire des compilateurs et SDK alternatifs pour d'autres plateformes, comme cela s'est vu avec beaucoup d'autres langages (Java (ex: compilation GNU gcj), C# (Mono)...etc).
Un langage de programmation n'est jamais vraiment propriétaire (car par définition sa syntaxe et sa grammaire est publique et documentée), il ne peut l'être qu'au tout début de sa vie, ou si personne ne s'y intéresse pour l'utiliser ailleurs que son usage originel.
Tu peux ouvrir les normes d'un langage, mais tu peux en restreindre l'usage, c'est une question de license.
Sans compter que tu as toujours besoin d'un compilateur qui lui est propriétaire.
Voilà un truc que les voleurs de la Corée du Sud auront bien du mal à copier !
@6ix
Effectivement, tout comme JS, à première vue très élémentaire, permet de faire des choses étonnantes. Il n'y a qu'à voir ce que Google, ou Apple, proposent dans les applications en ligne.
Par rapport à Objective-C, c'est l'entrée en matière qui est plus simple, après vous avez entièrement raison les notions de plus haut niveau demeurent difficiles.
@Ellipse :
Même si à part la syntaxe (que l'on retrouve ailleurs également), Swift ne me fait pas spécialement penser à JavaScript.
Comme softjo, ça me ferait plutôt penser à Scala par exemple (langage assez concis, multi-paradigmes).
C'est un mixte entre Python pour le degré d'abstraction et le tapage des données et Java pour la syntaxe.
Rien de bien révolutionnaire, pas mal quand même !
Swift me rappelle le Scala.
Idem, à priori c'est un excellent langage, reste à voir les perfs de l'implémentation de référence dans la vie réel, la volonté de faire sortir ce langage en dehors d'iOS/OS X.
Quelle est la licence, les brevets associés, Apple va-t-elle gérer seule l'évolution du langage ?
Enfin cela simplifie tout un ensemble de grosses lourdeurs syntaxiques de l'ojbc.
basé LLVM et runtime obj-C, il sera géré par Apple seul. Il devrait être opensource vu que les 2 briques de bases le sont.
Si d'autres sont intéressés, qu'ils piochent. Mais ça reste avant tout la création d'apple pour répondre aux exigences de cocoa/xcode et profiter des avancées permises par LLVM (le debuggage dynamique, etc)
Franchement, je trouve swift super bien foutu. Cela mérite largement de dépasser le cadre d'Apple. De son plus fort typage (pas de conversion explicites etc...) il penche plutôt vers une structuration à la Pascal qu'au 'b*rdel' de la famille C?? C/C++/C#/Objective-C/javascript etc...
Au final, le développeur devrait commettre moins d'erreurs.
C'est du beau travail. Vraiment.
Objective-C est typé fort
Qu'il soit permis d'utiliser le type id ne changeait pas cela. On a une sorte de choix.
Bon, allez, je me sens moi aussi autorisé à verser dans la nostalgie ....
La concision d'un langage (moins d'instructions ou de caractères pour arriver au même résultat) est un des éléments mis en avant par Apple (car il frappe les esprits) dans la présentation de Swift, mais il n'est nullement déterminant.
Je me souviens (cela ne nous rajeunit pas ...) des partisans du langage APL, présentant triomphalement des instructions hyper compactes , mais ... illisibles et non maintenables. Qui se souvient encore d'APL ?
La "compacité", l'élégance (ou la lourdeur ...) de sa syntaxe, sont des éléments d'appréciation d'un langage, mais finalement anecdotiques vis à vis de son succès ou de son échec.
Sans revenir sur le large débat que mériterait l'échec d'ADA (hormis quelques niches, ce qui n'était pas le but visé au départ ..) , l'expérience montre que le succès ou l'échec d'un langage repose sur bien autre chose que ses qualités intrinsèques (p ex , de manière tout à fait "sordide", disponibilité de compilateurs efficaces, non buggés, et rapides, et ... nombre de programmeurs formés au langage ...).
Je ne suis pas en état de me placer sur le plan des qualités intrinsèques de Swift, et ce genre de débat serait "pour spécialistes only", car il aborde des considérations très abstraites, mais en tout cas pour ce qui est des aspects non-techniques, le langage Swift a toutes les chances pour réussir dans l'écosystème Apple. Si, d'une certaine manière, la naissance d'un nouveau langage est en effet quelque chose de banal, le support clair et publiquement revendiqué de Apple envers ce nouveau langage est un évènement de grande portée, dont on n'a pas fini d'entendre parler, à mon avis.
@umrk
Qui se souvient encore d'APL ?
Nous devons être quelques un ici à connaitre ainsi que la citation du grand Edsger Dijkstra : APL is a mistake, carried through to perfection. It is the language of the future for the programming techniques of the past: it creates a new generation of coding bums <:i> :-)
Ca à l'air d'etre un bon langage, mais .. un langage de plus ...
la vie d'ingénieur. Y a pléthore d'outils pour pléthore d'usages.
Les syntaxes ne sont guère complexes à apprendre, le framework reste le même. C'est dans Cocoa que réside la complexité.
test
Du coup, pour quelqu'un qui n'a jamais touché à la programmation ? ( à part HTML/CSS .. ) est-ce que c'est possible de l'apprendre plus facilement que l'objective-C par exemple ? J'imagine qu'il faut déja de solides notions de C/Obj-C ...
S'il vous plaît MacG pondez nous un dossier pour débutant total pour créer une appli très simple pour iOS en rendant ça ludique :3 ! Ca serait tellement génial..
Sachant qu'iOS 7 est parti pour durer (il reste énormément d'iPhone 4 en circulation), et qu'on ne peut développer que pour iOS 8+ en Swift, il ne sera pas envisageable de proposer une app codée seulement en Swift avant au moins deux ans.
Je recommande donc de se mettre à Xcode maintenant en Objective-C. La syntaxe est nulle, mais faire une app basique reste assez simple.
dans la pratique, Swift devrait être marginalement + simple que objective-C à apprendre
vous êtes toujours concrètement obligé de bouffer les principes de
- programmation objet ! OUI !
- typage !
- généricité
-
je dirai que ça n'a rien à voir avec HTML/CSS. Rien à voir. HTML/CSS c'est en gros décrire un document Word mais en tapant la structure du format qui le décrit à la main.
Swift ou objective-C, c'est de la programmation d'ordinateur : boucle, conditions, variable, fonctions, déclarations.
-
pour Apprendre,
ALLEZ SUR LE SITE APPLE
Cessez de SOUS-ESTIMER le site APPLE !
http://developer.apple.com
oui tout est en anglais, mais une vie d'informaticien est en ANGLAIS (fin de tout débat)
Le site propose des tutoriels, des explications des principes de _Base_ (enfin, faut savoir ce qu'est un clavier)
Il y a un exemple pour débuter avec Swift utilisant Xcode Playground (faut la beta de xcode 6 et c'est de la BETA). C'est bien fichu, mais encore beta (comprendre: fragile)
Faire des logiciels en swift devrait être fonctionnel avec la sortie de Os X 10.10 et Xcode 6.
-
Coté objective-C que je recommande, car c'est le présent de COCOA, il y aussi pléthore d'explications, tutoriels et vidéo dispo via le site Apple.
Xcode lui même a des assistants et Apple fournit une application "simple" pour apprendre (en gros, quasi Textedit).
Lisez le site Apple. Il faut commencer à la source. Il n'y a pas besoin d'un compte développeur payant pour accéder aux documentation textes.
Vous êtes libre de payer des bouquins et sites qui paraphrasent le site Apple aussi. C'est un choix.
https://developer.apple.com/library/mac/navigation/#section=Resource%20Types&topic=Getting%20Started
curieux, mais j'aurais tendance à avoir la même opinion qu'Apple : c'est une modernisation d'objective-C.
<\i> ou plutôt, pour mettre fin aux italiques sur iPad. En tout cas je teste ;)
@SMDL
Et ça marche. Ouf ;)
Pages