Discussion :

[23JFK]

La syntaxe de swift paraît bien moche. Quelque part entre le Pascal et le Basic avec une surdose de ML. Bref, ça fait plus années 1970's que 2015's.

[foetus]

La syntaxe de swift paraît bien moche. Quelque part entre le Pascal et le Basic avec une surdose de ML. Bref, ça fait plus années 1970's que 2015's.

Explique un peu ce qu'est un langage 2015 je suis curieux

[23JFK]

Explique un peu ce qu'est un langage 2015 je suis curieux

un langage plus efficace et esthétique que le c++. Un truc qui ne me fait pas penser: années_disco -> [coiffure: "rouflaquette" , chemise: "col pelle à tarte" , pantalon: "patte d'elephant"] ... Swift fait dans le verbiage inutile/inesthétique du genre let x = , var ... as type , func, opérateurs assignements (a,_,(y,z)) ... ? Passer sa journée à taper des trucs pareils sur un clavier Apple à chaque fois que l'on déclare une variable, faut vraiment avoir la foi - je trouve. le langage 2015 reste à priori à inventer ^^' ; mais je sais d'ores et déjà que ce ne sera pas swift.

[DonQuiche]

Tout comme si toi tu trouves C# très bien, ça empêche pas pour autant MS de bosser sur F#.

F# n'a aucunement vocation à remplacer C# et ne découle pas des limites de ce dernier. C'est un langage fonctionnel, ce qui le positionne sur une certaine niche (même si une minorité voudrait qu'on utilisé ces langages partout ou plus largement).

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.

Je suis d'accord avec la dernière partie : c'est cette orientation mobile qui justifiait le passage au comptage de références. Mais ça reste un choix technique débattable, dont les avantages ne sont pas si clairs que tu le penses et je t'invite à te pencher sur les mesures réalisées par des tiers pour comparer les deux solutions made in Apple pour voir que ARC n'a pas en général d'avantage (et pourtant il me semble que leur GC n'était pas terrible).

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

On a bien compris que pour toi tous les choix de Apple étaient judicieux.

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

[madfu]

C'est amusant comme chaque nouvelle sortie de langage suscite autant de remous.

Sincèrement je ne comprends pas ce refus de passer à autre chose, un langage construit sur de l'inférence de type, l'intégration de closures, et d'une manière générale une syntaxe - quoi qu'en dise - LARGEMENT épurée comparée aux horreurs qu'on écrivait en Objective-C (heureusement que xcode offrait une bonne aide à la saisie), rien que pour ça je dis oui.

D'une manière plus "égoïste" c'est vrai que je retrouve là des concepts de langages que j'affectionne comme Groovy, Coffeescript, Ruby ou même Javascript. Là ça me redonne envie de faire de l'iOS natif, et j'espère qu'Android abandonnera un jour Java pour quelque chose de plus....moderne justement.

[rawsrc]

j'espère qu'Android abandonnera un jour Java pour quelque chose de plus....moderne justement.

Je pense que Google se la joue discret avec Dart pour l'instant, mais m'est d'avis qu'ils placent beaucoup d'espoirs en lui...

Le choix de java pour Android était stratégiquement brillant, maintenant qu'ils sont confortablement établis à tous les niveaux, ils ne leur reste plus qu'à ôter cette épée de Damoclès agitée par Oracle au sujet de Java et, pour le coup, on ne me retirera pas de l'idée que tous les efforts déployés pour Dart ne visent pas qu'à pondre un banal langage compilable en Javascript...

[Kearz]

En dehors du débat sur le langage en lui même (je n'ai jamais fait de l'objectif-C) est-ce une bonne idée?
Les développeurs iOS, ont-ils envie de changer de langage et essuyer les plâtres de swift?(même s'il est proche) S'ils faut s'adapter à un nouveau langage ils ont peut-être intérêt de se tourner vers d'autre plateforme non?

Les parts de marché de l'iphone sont en baisses. C'est peut-être temps d'aller voir ailleurs ou de regarder côté crossplateform?

(Maintenant, il est vrai que les autres plateformes peuvent faire la même chose du jour au lendemain.)


[TROLL du vendredi]
Et puis franchement, swift? S'ils voulaient prendre un nom de voiture ils auraient choisir 911, carrera plutôt que swift vu le prix de leur smartphone
[/TROLL]

[DonQuiche]

En dehors du débat sur le langage en lui même (je n'ai jamais fait de l'objectif-C) est-ce une bonne idée?

Si tu savais à quoi ressemble cette horreur d'objective-C tu comprendrais que, oui, les développeurs iOS vont l'adopter aussi rapidement que possible. Même si l'objective-C restera sans doute nécessaire pour certaines choses vu qu'il n'y a pas d'arithmétique de pointeurs dans Swift si je ne m'abuse.

[kOrt3x]

L'Objective-C n'est pas une horreur, pas plus que du JAVA.
Apple a toujours eu comme but de simplifier au maximum l'usage de leurs matériels, de leurs logiciels et s'ils peuvent simplifier leur langage de programmation, pourquoi s'en priver ?

[Le Vendangeur Masqué]

En dehors du débat sur le langage en lui même (je n'ai jamais fait de l'objectif-C) est-ce une bonne idée?

Comme le dit kOrt3x, le but d'Apple est probablement de simplifier le développement et de l'adapter au mieux à leur usage. Ce qui dans le fond n'a rien de stupide. La vraie question est de savoir si l'objectif est atteint, mais ça va falloir swifter un peu pour s'en rendre compte…

Après certains ici critiquent qu'Apple n'ai pas choisi d'employer un langage déjà existant. Mais cela semble difficile compte tenu par exemple dont ARC gère la mémoire (et Apple ne voulait visiblement pas d'un ramasse-miettes).
Et dans l'absolu c'est pas plus stupide que quand Microsoft a créé le C# alors qu'il aurait pu se contenter de promouvoir l'usage du C++ ou de Java.

Les développeurs iOS, ont-ils envie de changer de langage et essuyer les plâtres de swift?(même s'il est proche) S'ils faut s'adapter à un nouveau langage ils ont peut-être intérêt de se tourner vers d'autre plateforme non?

Envie ça j'en sais rien (enfin pour les autres), mais je crois qu'ils sont comme moi sûrement curieux de voir ce que ça donne. Après tout Apple est connue pour apporter régulièrement de sérieuses évolutions à ses plateformes (Mac OS->OS X, iOS, 32->64bits, 68k/PPC/x86/x64/ARM/Ax, et une foultitude de nouvelles API…). Ceux qui n'aiment pas le changement ne sont déjà pas chez Apple.

Ensuite il y a d'autres points à prendre en compte:
1/ Rien n'oblige à se mettre à Swift tout de suite. Je me souviens d'ailleurs que la transition C et autres vers Obj C lors du passage à OS X a duré des années. Et pour l'anecdote ce ne sont clairement pas les grandes entreprises qui donnent l'exemple. Ceux qui ont mis leur nez dans le code de Photoshop ou Office Mac sauront de quoi je parle…
et vu la proximité des deux langages et qu'ils se basent sur les mêmes outils et technologies (ARC/LLVM/Xcode), ObjC pourrait bien continuer d'être proposé pendant une décennie. Après tout Xcode propose bien toujours de compiler du C ou du C++…
2/ Je ne crois pas qu'il puisse y avoir énormément de bugs à cause de Swift, car comme je le disais ci-dessus derrière ce langage il y a des outils et des technologies déjà éprouvées avec ObjC.
3/ Changer de platforme c'est changer de business model et quelqu'un pour qui l'informatique est un métier ne prendra pas ce risque à la légère, ou jusqu'à parce qu'un langage serait plus ou moins cool.
4/ J'ai jeté un oeil à la doc de Switft (très bien faite au passage), je n'y ai rien vu d'insurmontable pour un programmeur moyen. Car on y retrouve nombre de concept venant d'objective C (comme la gestion mémoire avec ARC, les dictionnaires, …), mais surtout on retrouve les mêmes API qu'avec ObjC. Et comme il y a en a un paquet (merci Apple), c'est surtout ça qui aurait été compliqué à réapprendre. Travail considérable que tu devrais par contre obligatoirement faire en suggèrent bêtement de changer de plateforme (en plus du langage)…

Les parts de marché de l'iphone sont en baisses. C'est peut-être temps d'aller voir ailleurs ou de regarder côté crossplateform?

Aller voir ailleurs ? Tu veux dire sur des plateformes qui rapportent moins voir rien ? Tout ça pour sanctionner Apple d'avoir voulu faire évoluer les choses ? C'est sérieux ou tu mal placé ta balise [Troll] ?

Comme je l'ai dit dans un autre message, la part de marché ne donne pas d'indication sur la taille du parc (qui est en progression constante), ni sur son homogénéité, ni sur l'envie d'acheter de ses utilisateurs. 3 points sur lequel Apple est fort bien placé (et les deux derniers points où Android y est un peu à la ramasse).
Apple ne se limite pas à l'iPhone (Mac, iPad, et qui sait demain en plus iWatch, AppleTV, … ?), et pour info depuis quelques temps, et même en France on observe une remontée de la part de marché d'Apple. Ce qui signifierais qu'Android les gens trouvent ça très bien… tant qu'ils n'en n'ont pas.

(Maintenant, il est vrai que les autres plateformes peuvent faire la même chose du jour au lendemain.)

Tout comme la sortie du C# n'a pas l'air d'avoir précipité la fin de Microsoft…

[TROLL du vendredi]
Et puis franchement, swift? S'ils voulaient prendre un nom de voiture ils auraient choisir 911, carrera plutôt que swift vu le prix de leur smartphone
[/TROLL]

Pourtant y'a pire:

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

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

[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

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

[kOrt3x]

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

Non, je n'ai pas encore tester ce nouveau langage, mais je pense qu'il est plus simple que l'Objective-C. Apparemment, il est bien passé chez les développeurs iOS/OS X.

[Franck.H]

Avez-vous testé Swift ?

Ca j'aurais bien aimé mais je suis sur PC mais je possède un iPhone 5s, j'aurais bien aimé créé des applications pour mon mobile mais il n'existe pas, à ma connaissance, d'outils pour développer avec ce langage sur Windows