Traduction de la documentation officielle de Swift, Réactions à la publication du 10/06/2014

[Lionel]

Nous donnons la parole aux membres de Swift Code:

Bonjour,

Je me permets de vous contacter pour vous signifier que nous avons entrepris avec plusieurs développeurs iOS de publier une traduction en français de la documentation officielle de Swift, le nouveau langage de programmation dévoilé par Apple lors de la WWDC du 2 juin 2014.
Cette traduction est en cours pour le moment mais avance chaque jour un petit peu. Elle est disponible à l’adresse http://www.swiftcode.fr et devrait petit à petit se transformer en tutoriels accessibles même aux développeurs les plus débutants.
Mon équipe et moi-même serions ravis de pouvoir contribuer à l’émergence de ce nouveau langage et à l’engouement de la communauté francophone.
Lien vers le billet original

[zoso2k1]

superbe initaitive.

[apocrypha]

nous avons entreprit

J'espère qu'ils sont plus forts en traduction qu'en grammaire

Ce message a été modifié par apocrypha - 10 Jun 2014, 07:07.

[pom-pom-pom]

nous avons entreprit

J'espère qu'ils sont plus forts en traduction qu'en grammaire

justement, il cherche quelqu'un d'érudit comme toi pour corriger leur traduction....

[Sgt.Pepper]

justement, il cherche quelqu'un d'érudit comme toi pour corriger leur traduction....

Qu'il est amusant de lire qu'une orthographe et une grammaire correctes ne peuvent être que l'apanage d'un érudit.

S'il n'y a, par ailleurs, aucun scandale à commettre des fautes, pourquoi y en aurait-il à les corriger ?

Je me permets de vous contacter pour vous signifier que nous avons entrepris avec plusieurs développeurs iOS de publier une traduction en français de la documentation officielle de Swift, le nouveau langage de programmation dévoilé par Apple lors de la WWDC du 2 juin 2014.
Cette traduction est en cours pour le moment mais avance chaque jour un petit peu. Elle est disponible à l'adresse http://www.swiftcode.fr et devrait petit à petit se transformer en tutoriels accessibles même aux développeurs les plus débutants.
Mon équipe et moi-même serions ravis de pouvoir contribuer à l'émergence de ce nouveau langage et à l'engouement de la communauté francophone.

[gaelw]

Surtout quand le sujet de l'article est la langue française, un effort minimum s'impose

[scoch]

Oui, très bonne initiative, c'est encore plus plaisant de lire dans sa langue maternelle. Avec en option le téléchargement en pdf, c'est nickel !

Quant aux fautes d'orthographe et coquilles, je suppose qu'on les signale à l'aide des commentaires ? (sur swiftcode.fr, pas sur MacBidouille )

Ce message a été modifié par scoch - 10 Jun 2014, 08:41.

[lyonnel4]

J'ai comparé les premiers chapitres et c'est bien mieux niveau grammaire que le message envoyé à macbidouille (bien heureusement car j'avoue que ça m'aurait vite fait aller voir ailleurs, même chez les anglophones.).
D'ailleurs, ce n'est pas du tout une traduction au mot à mot. J'ai même du mal à appeler cela une traduction tellement ça diffère du guide d'Apple.

[zero]

Quant aux fautes d'orthographe et coquilles, je suppose qu'on les signale à l'aide des commentaires ? (sur swiftcode.fr, pas sur MacBidouille )

+1

[Sgt.Pepper]

Quant aux fautes d'orthographe et coquilles, je suppose qu'on les signale à l'aide des commentaires ? (sur swiftcode.fr, pas sur MacBidouille )

En effet, sur MacBidouille, quel intérêt ? Pour faire des érudits ?

Surtout quand le sujet de l'article est la langue française, un effort minimum s'impose

Maximum, devrais-tu dire.

[yponomeute]

J'ai comparé les premiers chapitres et c'est bien mieux niveau grammaire que le message envoyé à macbidouille (bien heureusement car j'avoue que ça m'aurait vite fait aller voir ailleurs, même chez les anglophones.).
D'ailleurs, ce n'est pas du tout une traduction au mot à mot. J'ai même du mal à appeler cela une traduction tellement ça diffère du guide d'Apple.

On n'a pas du lire les mêmes pages. Même mon correcteur orthographique (qui est loin d'être un érudit) trouve que c'est loin d'être parfait.

Edit : syntaxe

Ce message a été modifié par yponomeute - 10 Jun 2014, 09:14.

[ekami]

Mille mercis à cette valeureuse équipe de se lancer dans une traduction de Swift.
On s'arrangera avec les fautes de français, pourvu que les exemples de code ne soient pas buggés.
--
C'est curieux que cette "Swift révolution" soit passée inaperçue.
Pourtant, c'est un immense travail qui a été réalisé par l'équipe de Swift.
Bien sur, ce n'est pas aussi médiatique qu'HyperCard en son temps (Apple avait peu de logiciels à l'époque) avec son langage en anglais (presque) courant.
Simplifier la programmation va rendre la courbe d'apprentissage plus douce pour ceux qui veulent apprendre.
Je pense aux plus jeunes qui veulent s'initier (j'ai eu des demandes de gosses de 10 à 12 ans qui voulaient s'y mettre, et le plus jeune inscrit à la WWDC '14 avait 13 ans)
Apple joue une belle carte en permettant à plus de personnes (surtout les plus jeunes) de se lancer dans la programmation.
Sinon, il y a LiveCode, (HyperCard puissance 100 ): il est cher, mais il compile pour Mac/Win/Linux/iOS/Androïd, ce qui n'est pas rien !

[noxx09]

Super initiative, surtout pour les débutants pour lesquels l'anglais est un obstacle supplémentaire. Merci de l'initiative.

[ledter]

que de pubs...

[Ambroise]

C'est curieux que cette "Swift révolution" soit passée inaperçue.
Pourtant, c'est un immense travail qui a été réalisé par l'équipe de Swift.
Bien sur, ce n'est pas aussi médiatique qu'HyperCard en son temps (Apple avait peu de logiciels à l'époque) avec son langage en anglais (presque) courant.

C'est vrai : Swift mériterait d'être un sujet central.
J'ai dévoré le bouquin founi par Apple, "The Swift Programming Language" et je suis assez bluffé.
Du point de vue général, le code Swift a à chaque fois son équivalent en C++11/14, ce qui laisse augurer de bonnes performances sur le code compilé mais il est infiniment plus simple à écrire car les choix d'implémentations sont limités par le langage, donc implicites, alors qu'il faut les qualifier explicitement en C++.
Swift va visiblement souffrir des mêmes problèmes de performance que le Java ou le C# (en dehors du code #unsafe) vu qu'il ne semble pas possible d'organiser linéairement la mémoire et de profiter des prefetchers des CPU : si j'ai bien compris un container d'objets ne stocke pas les objets mais juste des references. Mais Swift semble avoir une grammaire plus agréable et simple que Java et profitera des avantages du code natif.

Par contre il est possible que Swift ne soulève pas encore des foules enthousiastes parce que sa syntaxe, bien qu'elle ressemble à 95% à une copie de C#, semble avoir subit quelques retouches tardives qui pourraient laisser penser que Swift 2.0 sera plus propre et moyennement rétro compatible avec Swift 0.9b... (Comme par exemples les paramètres d'une fonction qui peuvent s'écrire !param, #param, param:, param?, .param, #param?:, inout param, "param", &param, $0 ...)

[igerard]

Je ne crois pas que ce soit des retouches tardives... Je ne vois ps bien ce qui peut te faire penser cela ?

Les innovations du côté des énumérations sont pas mal du tout, et je ne vois pas bien où est l'équivalent en c++, cela et ça fait 2 ans que je n'en fais plus.

ça c'est assez nouveau pour moi...

Code

enum ServerResponse {
    case Result(String, String)
    case Error(String)
}

let success = ServerResponse.Result("6:00 am", "8:09 pm")
let failure = ServerResponse.Error("Out of cheese.")

switch success {
case let .Result(sunrise, sunset):
    let serverResponse = "Sunrise is at \(sunrise) and sunset is at \(sunset)."
case let .Error(error):
    let serverResponse = "Failure...  \(error)"
}

Quoi que leur exemple avec un type énuméré BarCode soit plus parlant... Voir dans le bouquin...

----

Par contre des syntaxes de python du style

Code

missing = list("STATUS=M|"+self.past_dict[o] for o in self.removed() if dict(item.split('=') for item in self.past_dict[o].split('|'))['HIT'] == 'Y')

Ne sont pas possibles dans Swift...

Alors que ce qu'ils ont fait sur le 'switch' est du même acabit... très très expressif... On peut imaginer que d'ici la release il y aura des nouveautés, car le langage va évoluer.

PS : Y'a 5 exemples de projets Swift dans la doc dev de xCode6 / Yosemite 10.10 / iOS8, dont un jeu fait avec SpriteKit qui permet de voir en détail la syntaxe Cocoa/Swift... instructif.

Ce message a été modifié par igerard - 10 Jun 2014, 11:39.

[scoch]

Et il y a déjà pas loin de 700 dépôts de code Swift sur GitHub.

[apocrypha]

Heureusement que j'avais mis deux smileys pour montrer que c'était de l'humour...

[Montréal]

Merci à cette équipe, je pense que ce sera utile à beaucoup de monde. Tiens, et si je m'y mettais ?
Quand aux fautes de français et au débat qui a suivi, je pense que le minimum est de savoir s'exprimer correctement dans sa langue maternelle, mais qu'il faut garder à l'esprit le contexte : Le fait de taper sur un clavier est générateur de fautes, alors laissons passer le bémol mais soyons sévère avec l'inculture !
Pour ceux que ça amuse de rire, qu'ils consultent les posts de sites québécois, les rédacteurs amateurs présents sur Mac Bidouille leur paraîtront fort érudits…

[scoch]

J'ai trouvé cette liste présentant les origines de certains éléments de syntaxe Swift.

Ada :
param names
in-out params

Bash :
$0, $1... inside short callback closures

C :
typealias
struct
control structures
labeled statements AKA gotos
varargs

C++ :
default arguments
class instance construction syntax
// comment
superclass, implementing protocol declaration syntax
semi-virtual class init, deinit

C# :
properties
subscript access of class member values

Go :
No parentheses around the condition part of control statements
Unicode identifiers
shorthand for signed and unsigned integer types U?Int(8|16|32|64)

Java :
enum
@final
override method keyword

Objective-C :
ARC
protocols
extensions
willSet/didSet
nil?

Python :
for i in enumerate(seq)
for key, value in dictionary
Type(value) explicit type conversion syntax
No public/private/protected class member access modifier bullshit
Array literals, dictionary is also like Python but use [] instead of {}

Ruby :
0..100, 100_000

Scala :
Local type-inference, blend of an ML flavored FP with OOP without the noise and believe it or not, even more powerful in specifying generic type constraints. No stupid JVM type erasures either so you can actually create an instance of a generic type, just like C++ templates.

Scheme :
closures
? optional type modifier

Smalltalk :
super keyword
self

Swift :
break-less switch, optional fall-thru, comma as multiple case, case can be any value of any type, condition or a type constraint for pattern matching, supports method call shorthand
generic type constraint queries
overflow operators
@prefix, @postfix, @infix, @assignment modifiers for operator overloading Trailing closure as partial function application
Gripes

Edit : corrections suite au commentaire de @igerard, et noms des langages ordonnés alphabétiquement.

Ce message a été modifié par scoch - 10 Jun 2014, 16:14.

[Antonin ENFRUN]

Par contre des syntaxes de python du style

Code

missing = list("STATUS=M|"+self.past_dict[o] for o in self.removed() if dict(item.split('=') for item in self.past_dict[o].split('|'))['HIT'] == 'Y')

Ne sont pas possibles dans Swift...

C'est pas un mal, parce que la c'est illisible


Tu peux avoir à peu près l'équivalent d'une list compréhension avec map, qui accepte un bloc de code anonyme : ex

Code

var badies = Array(1...6).map { num in SKSpriteNode(imageNamed: "Small Bad \(num)") }

ou

Code

var badies = Array(1...6).map { SKSpriteNode(imageNamed: "Small Bad \($0)") }

si tu ne veux pas nommer tes arguments.

[El Bacho]

C'est curieux que cette "Swift révolution" soit passée inaperçue.

Inaperçue où ? ArsTechnica a un excellent article de fond sur trois pages denses, MacG a consacré plusieurs articles à Swift et aux réactions des développeurs, même Mac4Ever a brièvement présenté la syntaxe. À peu près tous les sites Mac ou généralistes ont commenté le pari et les enjeux liés à Swift.

[igerard]

"super" et "self" viennent de smalltalk

le nomage des arguments (dès qu'on les nommait, l'ordre importait peu), j'en pratiqué ça avec Ada dès 88, 1 ans avant ma découverte d'ObjC.

in-out : ADA aussi, peut être pascal

Closure : Scheme (jamais pratiqué par contre)

...

A première vue, de mémoire...

PS : Wiki donne la closure dans Scheme en 75...

Par contre des syntaxes de python du style

Code

missing = list("STATUS=M|"+self.past_dict[o] for o in self.removed() if dict(item.split('=') for item in self.past_dict[o].split('|'))['HIT'] == 'Y')

Ne sont pas possibles dans Swift...

C'est pas un mal, parce que la c'est illisible

Je suis tombé sur ce code en maintenance au taff... Oups... J'ai mis un petit moment à me convaincre que ça faisait ce que c'était censé faire... Tu as raison je préfère la notation que tu proposes... beaucoup plus maintenable.

Un exemple : http://stackoverflow.com/questions/1165352...thon-dictionary

PS : Par contre, Swift avec le 'where' pourra étendre la syntaxe pour ce genre de chose, ce qui sera plus lisible que le 'if' enchainé... A voir


Ce message a été modifié par igerard - 10 Jun 2014, 13:45.

[scoch]

@igerard, bien vu j'ai modifié la liste.

Ils sont très réactifs sur www.swiftcode.fr, je leur ai envoyé des corrections orthographiques et c'est déjà intégré !

[Chriz]

Ils perdent leur temps: Apple aura déjà fait le switch vers un autre langage qu'ils auront à peine terminé la traduction (Ok, I'm out!)

[Som]

Tout qu'une innovation ce langage.
Au fait il s'agit d'une nouvelle syntaxe et grammaire. Au niveau des langages de programmation il n'a y a rien de nouveau à apprendre. Et si l'on a bien appris le C on a appris pas mal.

Maintenant, vouloir faciliter la chose au programmeur… et avoir des des programmeurs à la vb (C#) n'augure rien de bon. On voit où ça a conduit microsoft et Ballmer qui ne cessait de répéter Programer programer programer.

[Chriz]

Tout qu'une innovation ce langage.
Au fait il s'agit d'une nouvelle syntaxe et grammaire. Au niveau des langages de programmation il n'a y a rien de nouveau à apprendre. Et si l'on a bien appris le C on a appris pas mal.

Maintenant, vouloir faciliter la chose au programmeur… et avoir des des programmeurs à la vb (C#) n'augure rien de bon. On voit où ça a conduit microsoft et Ballmer qui ne cessait de répéter Programer programer programer.

Désolé, mais on peut développer une bonne application dans n'importe quel langage. Les talents du développeur diront si le produit est excellent ou bon pour la casse. On a vu les 2 extrêmes dans tous les langages. Et je ne vois pas en quoi Microsoft et Ballmer devraient avoir honte...

[r@net54]

Tout qu'une innovation ce langage.
Au fait il s'agit d'une nouvelle syntaxe et grammaire. Au niveau des langages de programmation il n'a y a rien de nouveau à apprendre. Et si l'on a bien appris le C on a appris pas mal.

Maintenant, vouloir faciliter la chose au programmeur… et avoir des des programmeurs à la vb (C#) n'augure rien de bon. On voit où ça a conduit microsoft et Ballmer qui ne cessait de répéter Programer programer programer.

Désolé, mais on peut développer une bonne application dans n'importe quel langage. Les talents du développeur diront si le produit est excellent ou bon pour la casse. On a vu les 2 extrêmes dans tous les langages. Et je ne vois pas en quoi Microsoft et Ballmer devraient avoir honte...

Tout a fait d'accord, un bon programmeur fera un bon programme avec presque n'importe quel langage, après c'est le temps qu'il va y passer qui sera révélateur.

Mais Apple avec Swift a fait deux constatations:
- les dérivés du C sont obsolètes et générateurs de bug sur les machines et surtout OS actuels
- la plateforme OS X / iOS connait un afflux massif de nouveaux programmeurs dont beaucoup ont appris sur le tas sans passer par des formations sérieuses

Cela ne veut pas dire que les programmeurs autodidactes sont forcement mauvais, au contraire. Mais il faut se rendre a l'évidence que si Apple veut sécuriser ses plateformes, cela passe aussi par la simplification de la programmation des App.
Si le langage favorise les buffer overrun, l'oubli de desalocation de mémoire, l'utilisation de variables non allouée, les boucles infini, les allocations dans les test, les goto, les points de sorties ou d'entrées multiples dans les procédures, les mutations non contrôlées explicitement, les allocations hors de l'espace de l'application, etc, alors le risque de bug et de faille est majeur, meme pour un très bon programmeur.

De plus pour que la programmation soit attrayante, il faut que la plateforme soit rentable (ça c'est déjà bien le cas) et que la réalisation soit simple et expressive.
J'ai beau avoir appris a faire de l'optimisation d'allocation mémoire a l'aide de l'arithmétique sur les pointeurs en C, j'avoue que cela arrive en toute derniere phase après la mise au point de la logique du programme, de l'optimisation des algorithme et du debbuging... En plus sur une plateforme ou il y a une API pour a peu près tout, ou l'on va quasiment jamais adresser le processeur directement et ou de toute façon on sait que le processeur va faire sa cuisine interne en réarrangement le code pour l'optimiser, les pointeurs sont plus un handicap qu'une optimisation.

De plus je me suis forme sur ADA, Lisp et Prolog, et comme tout programmeur actuel je vais pas attaquer le problème avec du C mais avec un langage de haut niveau comme Python...
Comme disait B.Meyer le C c'est ce qu'il y a plus proche d'un assembleur portable, c'est au compilateur de travailler avec pas au programmeur. En cela Eiffel est une (très) bonne approche mais très divergente de celle d'Apple avec Swift. Swift est fait pour programmer des API d'un OS (on va probablement avoir une version opensource,...) de manière la plus expressive possible et en évitant les erreurs classiques de programmation que le C favorise...

La très grosse erreur dans les années 90/2000 c'est d'avoir voulu améliorer C en lui rajoutant des concepts evolués comme la programmation objet. Le C a été conçu dans les années 70 comme un langage de bas niveau (juste au-dessus de l'assembleur) pour faire de la programmation système pour Unix, donc pour des programmeurs universitaires hyper specialises dans de l'optimisation de bas niveau. Il est clair que le C permet des optimisations qui sont seulement dépassées par une programmation assembleur directe, mais cette qualité impose une discipline et des connaissances pointus du domaine.
Rajouter des niveaux conceptuels a C est donc une aberration. Le pompon ayant été atteint avec C++, qui voulait empiler une couche objet venant de Simula et la sécurisation d'ADA... C'est devenu une usine a gas dont les meilleurs programmeurs ont utilise un sous ensemble pour faire de la programmation système...

Swift permet une grande expressivité en se basant sur plusieurs paradigme de programmation, a choisir en fonction du problème. Il permet aussi d'éviter nombre d'erreurs d'étourderies (qui peuvent arriver meme au meilleur) et est capable de traiter des classes de problème variées et jsuqu'a de très gros logiciels. C'est pas fait apparemment pour du bas niveau (encore que la recherche de faille de sécurité se fait majoritairement avec Python, donc un langage de script de haut niveau), mais Apple a l'air de penser le contraire...

La seule chose qui manque a mon gout c'est une gestion du parallélisme native. Mais a part ça, ça semble être un très bon langage.