Développeurs : Xcode 10.2 et Swift 5 sont finalisés
En même temps que les mises à jour d’iOS, macOS et tvOS fournies hier soir à tous les utilisateurs de produits Apple, les développeurs ont pu récupérer une nouvelle version de Xcode, l’outil de développement de l’entreprise. Numérotée 10.2, cette mise à jour corrige des bugs, notamment dans les Playgrounds1. La principale nouveauté toutefois est à chercher sous le capot.
En même temps que la version finale de Xcode 10.2, Apple a fourni la version finale de Swift 5, son langage de développement. C’est une version majeure, qui complète la stabilisation du langage initiée avec Swift 4, avec cette fois la stabilité des ABI. Pour les utilisateurs, le principal intérêt à court terme sera une réduction de la taille des apps, comme nous l’avions détaillé dans un précédent article :
Pour les développeurs, d’autres nouveautés sont proposées, avec la possibilité d’enregistrer du texte brut dans une variable, un cas inconnu pour les énumérations ou encore une fonction pour vérifier si un nombre est un multiple d’un autre. Pour tester toutes ces fonctions, vous pouvez télécharger ce Swift Playground qui les liste toutes, avec des exemples interactifs. Apple a aussi adapté son livre numérique sur Swift, pour prendre en charge les nouveautés de Swift 5.
Depuis Swift 4, le code source reste inchangé, ce qui veut dire que vous n’avez pas besoin de modifier votre code pour mettre à jour votre projet.
-
À noter que la bêta proposait une option pour activer le mode sombre de Xcode en permanence, même si macOS était en mode clair. Cette nouveauté n’a pas été conservée dans la version finale. ↩︎
watchOS fournit hier soir ? Un poil en avance MacG ;)
@letofzurichois
Oups, les réflexes… ?♂️
C’est plutôt un Xcode Playground car impossible de l’ouvrir dans l’app Swift Playground pour iPad.
« Pour les utilisateurs, le principal intérêt à court terme sera une réduction de la taille des apps »
À court terme, ça m’étonnerait beaucoup : pour qu’une appli n’embarque plus le runtime Swift, il faut qu’elle ne soit pas compatible avec une version antérieure à iOS 12.2. Autant dire que ça ne sera pas demain la veille pour les applis un poil sérieuses.
De ce que j'ai compris, l'App Store compile l'app pour ta version d'iOS spécifiquement, du coup il doit être facile de ne pas intégrer ces fichiers dans un version de l'app destinée à iOS 12. Dans les notes de versions ils mettent "App Store thins the Swift runtime from your apps for master downloads to Devices running lattes iOS".
Et vous macg à quand une appli moins lourde en swift? Mais qui soit compatible avec les autres versions antérieures d’iOS.
>une fonction pour vérifier si un nombre est un multiple d’un autre
MOD ?
(If var1 MOD var2 = 0 Then)
@Emile Schwarz
Me posant la même question (pourquoi implémenter un isMultiple() sachant que ‘a mod b’ permet d’avoir cette information, j’ai été voir l’implémentation et les discussions autour de cette fonction.
Alors, voici les trois raisons qui les ont poussés à implémenter cette fonction:
- Possible d’avoir de meilleure performance sur des grands nombres
- Éviter les bugs des restes négatifs
- Plus ‘simple’ que l’utilisation d’un modulo, surtout pour les nouveaux développeur.
Pour plus d’information:
- Le sujet d’acceptation de la modification : https://forums.swift.org/t/accepted-with-modifications-se-0225-adding-ismultiple-to-binaryinteger/15689
- L’implémentation de la modification : https://github.com/apple/swift/pull/18689/files
> - Possible d’avoir de meilleure performance sur des grands nombres
Possibilité *future*.
> - Plus ‘simple’ que l’utilisation d’un modulo, surtout pour les nouveaux développeur.
Du moins disant, quoi.
Je ne trouve pas "bénéfique" qu'un développeur, en particulier débutant, ne découvre pas - parce qu'on lui cache désormais - que tester la divisibilité et tester si le reste de cette division est zéro c'est pareil.
Mais bon, le niveau en math des développeurs n'est p'tet plus ce qu'il était.
Cela ne va pas arranger les choses, en tout cas.
@ byte_order : « Possibilité *future*. »
Ce qui est toujours mieux que pas de possibilité du tout.
« Du moins disant, quoi. »
Non, pas forcément. Parce que plus encore que « plus simple », c’est « plus expressif, plus explicite » qui est recherché : le but de l’opération est clairement affiché au lieu de devoir être déduit de la combinaison d’une opération mathématique et d’une comparaison.
D’autre part, un autre objectif est d’éliminer une erreur classique consistant à vérifier qu’un nombre est impair en faisant une comparaison à 1 plutôt qu’à 0.
« Je ne trouve pas "bénéfique" qu'un développeur, en particulier débutant, ne découvre pas - parce qu'on lui cache désormais - que tester la divisibilité et tester si le reste de cette division est zéro c'est pareil. »
Je comprends bien ce point de vue. Mais je ne peux pas non plus m’empêcher de me dire que s’il a fallu qu’un gars attende de se mettre à programmer pour comprendre le lien entre divisibilité et reste de la division, c’est qu’il faut s’inquiéter au sujet de son niveau en math.
Et juste pour chipoter : « parce qu'on lui cache désormais », c’est incorrect. On ne le lui cache pas — on lui offre juste une voie plus facile. ;-)
@BeePotato
> Ce qui est toujours mieux que pas de possibilité du tout.
Je vois pas ce qui empêche d'optimiser l'implémentation de l'opérateur modulo.
Ce qui aurait l'avantage d'en faire profiter le code pré-existant également.
> c’est « plus expressif, plus explicite » qui est recherché : le but de l’opération
> est clairement affiché au lieu de devoir être déduit de la combinaison
> d’une opération mathématique et d’une comparaison.
C'est ce que je dis : désormais, des gens se contenteront de se dire "okay, là on teste si tel chiffre est divisible par tel chiffre" sans être capable de (re)connaitre comment un tel test peut être fait.
En poussant cette logique pour toujours plus d'expressivité d'un langage jusqu'à l'absurde, on peut proposer une fonction faitCeQueJeVeux(), aussi. Les nouveaux programmeurs trouveront cela plus simple. Mais ils ne seront plus vraiment des "programmeurs", n'est-ce pas ?
Un ordinateur repose intégralement sur des mécanismes mathématiques - pour l'essentiel, les plus simples. Un programmeur qui ne maitrise pas un minimum les plus simples mécanismes mathématiques, est-ce bon sur le long terme de lui faire croire qu'il n'a pas à s'en soucier !?
> D’autre part, un autre objectif est d’éliminer une erreur classique consistant à vérifier
> qu’un nombre est impair en faisant une comparaison à 1 plutôt qu’à 0.
Cela ne l'élimine pas, puisque la source de cette erreur est là encore dans la non-maitrise des fondamentaux mathématiques appliqués à l'informatique.
> s’il a fallu qu’un gars attende de se mettre à programmer pour comprendre le lien
> entre divisibilité et reste de la division, c’est qu’il faut s’inquiéter au sujet de son niveau
> en math.
Mais plus on va abaisser le niveau en math requis pour envisager une formation à la programmation, plus le cas sera fréquent.
Et ce type de "facilité" introduit dans un langage participe artificiellement à baisser ce niveau, justement.
> Et juste pour chipoter : « parce qu'on lui cache désormais », c’est incorrect.
Exact, abus de langage de ma part.
> On ne le lui cache pas — on lui offre juste une voie plus facile. ;-)
Ou on l'incite à la dumbification.
Bref, c'est à la fois anecdotique et symptomatique, cet exemple.
@ byte_order : « Je vois pas ce qui empêche d'optimiser l'implémentation de l'opérateur modulo. »
Peut-être parce que le modulo doit renvoyer un résultat numérique, alors que isMultiple(of:) se contente de vérifier une condition, lui permettant d’éviter une (toute petite) partie du calcul ? C’est juste une hypothèse, car je ne me rappelle plus ce qui avait été dit à ce sujet.
Je signalais juste qu’une possibilité future, c’était toujours ça de pris.
« C'est ce que je dis : désormais, des gens se contenteront de se dire "okay, là on teste si tel chiffre est divisible par tel chiffre" sans être capable de (re)connaitre comment un tel test peut être fait. »
Si des gens arrivent là sans savoir qu’on peut faire ce test de cette façon (ou d’une autre, dans le cas des multiples de 2), c’est qu’ils n’ont pas suivi les bons cours. Est-ce au langage de se substituer aux cours qu’ils auraient dû avoir ?
Est-ce qu’on doit vraiment s’interdire d’ajouter des fonctions qui peuvent être pratiques pour tous les développeurs juste parce que ça ne permet plus à certaines personnes, en se retrouvant exposées aux détails d’implémentation, d’apprendre les concepts de base qu’elles auraient dû apprendre par ailleurs ?
D’autre part, ces mêmes personnes qui débarquent sans savoir qu’il y a un opérateur leur permettant de calculer le reste d’une division, ni savoir que c’est ce qu’il faudrait utiliser pour vérifier qu’un entier est multiple d’un autre, vont-elles vraiment apprendre tout ça en allant recopier un bout de code trouvé sur Stack Overflow, qui leur montre l’usage d’un opérateur dont rien dans la syntaxe (%) ne leur indique à quoi il sert ?
Et si on veut être positif, on peut se dire que certains des développeurs qui ont une vague idée qu’il faudrait utiliser cet opérateur mais se rendent compte qu’il y a, dans ce langage, une fonction dédiée à ce test, pourraient se demander pourquoi, aller se renseigner, et apprendre quelques trucs au passage, notamment sur les erreurs qu’il est possible de faire avec l’opérateur modulo.
« En poussant cette logique pour toujours plus d'expressivité d'un langage jusqu'à l'absurde, on peut proposer une fonction faitCeQueJeVeux(), aussi. »
Mais c’est déjà le cas.
Il y a plein de fonctions de ce genre dans les langages modernes, et plus encore dans les frameworks des OS modernes. Ça regorge de « magie » à tous les étages.
« Les nouveaux programmeurs trouveront cela plus simple. Mais ils ne seront plus vraiment des "programmeurs", n'est-ce pas ? »
Ce n’est pas nouveau, comme façon de voir les choses. On a pu lire ça de très nombreuses fois au fil de l’évolution des langages de programmation et des frameworks les accompagnant.
Je ne sais pas si on doit toujours considérer les développeurs actuels comme « des programmeurs » ou non. Mais ce que je sais, c’est que toutes ces évolutions et tous ces ajouts de fonctions « magiques » ont vachement simplifié de grandes parties du boulot de développeur, dégageant du temps pour d’autres parties plus intéressantes.
« Cela ne l'élimine pas, puisque la source de cette erreur est là encore dans la non-maitrise des fondamentaux mathématiques appliqués à l’informatique. »
C’est idiot, cette phrase : l’erreur est bel et bien éliminée si on n’a plus l’occasion de la faire.
Que la source de cette erreur soit aussi source d’autres erreurs n’y change rien.
« Ou on l'incite à la dumbification.
Bref, c'est à la fois anecdotique et symptomatique, cet exemple. »
Je pense qu’il faut vraiment se poser la question, comme je l’ai fait plus haut, de savoir si le but d’un langage de programmation est d’enseigner la programmation.
Je ne le pense évidemment pas. Tel ou tel langage peut être utilisé dans le cadre de l’enseignement, mais ajouter, lors de sa conception, la contrainte qu’il puisse servir à l’auto-formation, je trouve ça contre-productif. Surtout qu’il existe déjà suffisamment d’autres langages qui peuvent servir à ça.
Tout-à-fait d'accord. Mais force est de constater que la maîtrise des math (et du reste !) chez les apprentis-développeurs n'est (malheureusement) plus d'actualité et est réservée à une "élite". La faute (je pense) aux exigences en baisse au lycée (désastreuses) qui se répercutent sur le post-bac. Bon, ça permet au moins à ceux qui bossent vraiment d'avoir les "bonnes" places, c'est déjà ça. Les écoles de remise à niveau avant école d'ingénieur (pour les BTS, DUT etc.) s'arrachent les cheveux devant le nombre d'élèves incapables de bosser plus d'une heure par jour sur leurs cours (caricatural mais c'est ça).
Moi-même prof en informatique en BTS je rêve (cauchemarde ?) devant la passivité de la majorité. Le développement sérieux, ça s'apprend, et peu en sont vraiment conscients. :-(