Apple présente Pkl, un langage de programmation pour la configuration
Apple présente Pkl, prononcé pickle comme un cornichon, « un langage de programmation pour la configuration ». Les fichiers de configuration des environnements de développement, des intégrations continues ou d’autres projets sont généralement rédigés avec des langages statiques comme JSON ou YAML. Pkl veut faciliter leur création et surtout leur maintenance en apportant une plus grande expressivité et un mécanisme de validation.
Les langages statiques comme JSON ou YAML, sans parler des listes de propriétés au format XML largement employées par Apple, ont les inconvénients de leurs avantages. S’ils sont relativement lisibles, ils obligent généralement à répéter le code lorsque la configuration s’allonge, sans intégrer de mécanismes de validation pour éviter les erreurs. Les outils permettant de combler ces lacunes imposent une complexification de la syntaxe à l’opposé de l’objectif premier de ces langages.
Des langages plus généraux peuvent être utilisés pour générer des fichiers de configuration, mais comme ils n’ont pas été spécifiquement conçus pour cet usage, leur manipulation peut se révéler complexe. Pkl tente de résoudre la quadrature du cercle : c’est un langage aussi expressif que JavaScript ou Ruby, qui permet ainsi d’éviter de se répéter, mais spécifiquement pensé pour la rédaction de fichiers de configuration, qui peut ainsi produire aisément du code JSON, YAML ou encore PLIST.
« Nous voulons prendre le meilleur des deux mondes », explique Apple, « proposer un langage déclaratif, simple à lire et écrire, mais enrichi de fonctionnalités empruntées aux langages généralistes. » Pkl propose ainsi des classes, des fonctions et des structures conditionnelles. Les développeurs pourront créer et publier des paquets pour partager leur code, notamment pour intégrer des configurations Pkl aux chaines de production Swift, Go, Java ou Kotlin.
Apple dit avoir voulu concevoir un langage qui « détecte les erreurs de validation avant le déploiement », s’adapte « aux cas d’usage les plus simples comme les plus complexes » et surtout est « un plaisir à écrire grâce à nos excellentes intégrations aux IDE ». Pkl peut effectivement être intégré à IntelliJ, Visual Studio Code et Neovim avec des extensions, mais pas encore Xcode, comme le note malicieusement le développeur Marcin Krzyzanowski.
Pkl semble avoir été construit avec l’aide du framework de constructions de langages Truffle, qui repose lui-même sur le compilateur Java de la distribution GraalVM, l’un comme l’autre développés par Oracle. On comprend bien que ce langage navigue quelque part entre les plateformes d’Apple et l’univers Android. Apple propose une documentation complète avec de nombreux exemples et le code sous licence Apache sur Github.
Si c’est aussi bon par rapport à JSON que Swift par rapport à ObjC, j’ai hâte d’utiliser ça !
@ PetrusM
> Si c’est aussi bon par rapport à JSON que Swift par rapport à ObjC
Si c'est comme Swift, ce langage de Shadocks, avec la maxime "pourquoi faire simple quand on peut faire compliqué", alors je crains le pire. Mais qui sait...
Ceci dit, votre remarque montre que vous n'avez pas compris de quoi il s'agit :
D'un langage de programmation (a programming language for producing configuration) comme c'est dit dès le début de l'article.
Or JSON, c'est un format de données, pas un langage de programmation !
Et c'est là que se justifie ce nouveau langage, pallier aux insuffisances des systèmes basés sur du JSON plus quelque chose pour par exemple valider les configurations.
Vous y allez un peu fort en disant que je n'ai rien compris. Je veux bien qu'il s'agisse d'un langage de programmation, mais les exemples donnés montrent bien principalement un langage de stockage de données. Et qu'il y ait des branches ou des boucles dedans certes, mais ça restera à mi-chemin entre langage de programmation et langage de stockage de données.
Je ne pense pas que la comparaison avec JSON ou YAML soit déplacée : on ne peut pas y faire de branches, mais cela reste les ancêtres de Pkl, en matière de fichiers de configuration.
J'ajouterais que le langage le plus proche dont j'aie connaissance est celui utilisé dans les fichiers Gradle (Groovy si je ne me trompe), et qui semble avoir le même but (configuration de builds), à la fois en indiquant des données de configuration, mais en ayant également des instructions.
Enfin, je ne comprends pas la complexité que vous reprochez à Swift. Je trouve justement qu'il est nettement plus simple à employer, et beaucoup plus élégant, que d'autres langages que j'utilise (et j'en ai utilisé un paquet). Même pour un langage moderne : Kotlin par exemple est nettement un cran en dessous.
"Enfin, je ne comprends pas la complexité que vous reprochez à Swift.": de mon côté, j'avoue n'avoir jamais eu le courage de me pencher vraiment sur swift pour essayer de comprendre sa syntaxe, mais venant d'Objective-C, Swift est quand même affreusement repoussant, non? Surtout quand il était présenté comme un langage aussi adapté aux débutants…
Vous trouvez le Swift plus compliqué que l'Objective C ? Parce que vous êtes habitué à ce dernier, certes. Mais dans l'absolu, ça n'a rien à voir. Faire les mêmes choses qu'en ObjC (et surtout, en plus propre), est plus simple. Et après, les concepts plus poussés de Swift, permettant de faire des choses plus puissantes, n'existaient même probablement pas en ObjC.
Le Swift permet d'éviter un bon nombre de classe d'erreurs, de ne pas se préoccuper de retain/release,...
Et surtout, l'ensemble des concepts de Swift sont explicites et d'une syntaxe simple, donc adaptés aux débutants. Certains disaient même, au début, que c'était plus un langage-jouet qu'un vrai langage !
Je pense que vous dites cela parceque vous avez pratiqué beaucoup d'ObjC et que vous n'avez pas essayé sérieusement Swift (n'y voyez pas d'offense, c'est normal de préférer un langage qu'on pratique).
@ PetrusM
> les concepts plus poussés de Swift, permettant de faire des choses plus puissantes, n'existaient même probablement pas en ObjC
Probablement pas ?
Probablement ? 😳
Quant aux concepts, Swift est adoré par ceux qui maîtrisaient mal la programmation orientée objet. À la place, les structures sont conseillées, avec moult "protocoles" histoire qu'au final avoir une vue d'ensemble du code écrit par quelqu'un d'autre est très difficile sans documentation dédiée.
Swift est adoré par ceux qui ne maîtrisaient pas les pointeurs et en avaient peur.
À propos de pointeurs, les développeurs de Swift ont visiblement oublié que macOS est un Unix et qu'Unix est écrit en C et que nombre d'API sont des fonctions en C. Rien que pour récupérer une chaîne de caractères C en Swift, c'est tout une cuisine absolument pas intuitive comme je l'ai montré dans un exemple dans un autre commentaire.
Etc, etc.
Mais bon, faudra s'y faire j'en conviens, car Apple pousse Swift et a mis Obj-C sur une voie de garage.
"Swift est adoré par ceux qui maîtrisaient mal la programmation orientée objet"
Non. Rien à voir. C'est seulement un paradigme de POO un peu différent, plus moderne, et tenant compte des reproches faits aux langages précédents. Swift pousse la composition plutôt que l'héritage, par exemple. C'est de plus en plus conseillé ces derniers temps.
"Swift est adoré par ceux qui ne maîtrisaient pas les pointeurs". Pas d'accord non plus. Je maîtrise très bien les pointeurs, et je ne vois aucun intérêt à les préférer aux abstractions par Swift (en dehors de l'interface entre C et Swift). Et je ne parle pas des doubles pointeurs et autres joyeusetés. Swift est un langage de plus haut niveau, qui permet d'écrire les choses de façons plus concise. Et je ne parle pas des débutants, pour lesquels les pointeurs sont une notion difficile à appréhender. Et c'est bien vous qui disiez "Pourquoi faire simple quand on peut faire compliqué". Pour ça, les pointeurs se posent là comme exemple !
Je crois deviner à travers vos réponses que vous avez assez peu pratiqué le Swift.Essayez-le plus longuement sans a priori, et je pense que vous finirez par trouver que l'ObjC est plus complexe.
Enfin, sachez que j'ai passé il y a quelques années le logiciel que je développe de 100% ObjC à 100% Swift. Le nombre de lignes de code a été divisé par 3 et le nombre de bugs a drastiquement diminué. Et je trouve que la lisibilité s'en est trouvée accrue, permettant de se focaliser sur l'architecture du logiciel plutôt que sur les arcanes du langage.
@ marc_os : « Swift est adoré par ceux qui ne maîtrisaient pas les pointeurs et en avaient peur. »
Peut-être.
Cependant, écrit comme ça, on pourrait presque croire que le sens du message est que seuls ceux-à adorent Swift — apportons donc un peu de précision. 😉
S’il est probable que ceux qui n’aiment pas les pointeurs apprécient Swift parce qu’ils leur permet la plupart du temps de ne pas avoir à en manipuler, ils ne sont pas les seuls, et Swift est aussi très apprécié, pour la même raison ainsi que pour d’autres qualités, par des développeurs maîtrisant parfaitement les pointeurs et leur usage.
En complément j'ajouterais qu'il y a deux types de débutants :
- Les débutants qui font du dév pour s'amuser, et qui n'en feront pas leur métier. Dans ce cas, oui, on peut leur proposer des langages très simples et très permissifs, qui permettent de faire du vite fait-mal fait (qu'on appellerait en entreprise du prototypage). Je pense par exemple à Python (mais je n'en ai jamais vraiment fait, donc c'est une supposition). Cela leur permettra d'obtenir un résultat rapide, qui fonctionne, sans frustration.
- Les débutants qui veulent en faire leur métier. Dans ce cas, il est FONDAMENTAL que le langage avec lequel ils apprennent soit strict, ait un paradigme cohérent, et crache une erreur quand on tente de faire n'importe quoi. Parceque la rigueur, si elle n'est pas nécessaire pour les petits projets n'ayant pas vocation à devenir grands, est très importante pour les autres projets, et pour travailler à plusieurs. Pour ne pas avoir à tout recommencer à zéro au bout de trois mois. Et je pense que justement, le Swift est un langage permettant cela : il permet de tout faire, mais pas n'importe comment. Il permet d'apprendre les concepts de base, sa syntaxe est simple, on peut y faire beaucoup de choses MAIS pas n'importe comment.
@jerome74
Je pense que dans votre commentaire tout est dans le « mais venant d'Objective-C »
Objective-C quand on ne vient pas du C est juste un cauchemar (nb je suis développeur et j’utilise de nombreux langages mais pas le C)
Pour toute la nouvelle génération qui ne pratique pas le C Swift est infiniment plus accessible je vous l’assure !
@ jerome74 : « venant d'Objective-C, Swift est quand même affreusement repoussant, non? »
Repoussant si on tient beaucoup à l’envoi de message et au binding dynamique d’Objective C. Swift, bien que disposant de capacités dans ce domaine pour être compatible avec Obective C, est un langage pensé pour un autre mode de fonctionnement, reposant au maximum sur un typage statique et du travail au moment de la compilation, plutôt qu’au runtime.
Mais c’est vraiment une affaire de goût… et aussi de la partie d’Objective C qu’on utilise le plus. Car quand on parle de la simplicité d’Objective C, on a généralement tendance à se focaliser sur la partie objet, en oubliant le C sur lequel elle repose. Or selon l’usage qu’on a, cette partie C sera plus ou moins présente, et là on peut difficilement parler d’un langage simple. Surtout qu’on se retrouve avec deux langages en un, avec deux syntaxes et modes de fonctionnement bien différents. Swift, lui, tente d’unifier tout ça.
« Surtout quand il était présenté comme un langage aussi adapté aux débutants… »
Cf. ma remarque ci-dessus : je ne suis pas sûr qu’un débutant soit plus mal à l’aise face à Swift que face à du C. Et au moins, quand il en arrivera à avoir besoin de choses qui, en Objective C, nécessitent de faire appel à la partie C, en Swift il s’y attaquera en restant dans le même langage, la même syntaxe, la même logique.
Notons que j’écris tout ça alors que j’aime beaucoup Objective C depuis un bon moment. Ce n’est pas une critique de ce dernier ; juste un point de vue complémentaire sur Swift.
parce qu'il est ... complexe, chronophage et tellement dur à apprendre que lorsque tu dois travailler sur un projet d'appli pour android et iOS, tu dois avoir besoin d'un dev iOs et dev Android. ça fait cher payé pour avoir une application, sa maintenance alors que tu peux faire les 2 avec du PWA ou des framework multiplateforme comme flutter ou react/reactnative beaucoup plus sympa à utiliser et qui sont nettement plus utilisés !
En plus, ça évite d'avoir des différences au niveau interfaces et à l'usage...
@Dimemas
C’est l’inverse qui se passe en entreprise pourtant, plutôt que de faire une unique application moyenne/médiocre (car non native donc plus lente, moins optimisée, pas d’accès aux dernières nouveautés de l’OS - genre widgets raccourcis et cie - et du hardware…) qui va ruiner l’image de marque et coûter une blinde en SAV,
Ça vaut maintenant + le coup de faire plusieurs applications natives excellentes.
C’est tellement facile de partager du code entre projets qu’il n’y a plus d’excuses
C’est marrant, mais l’entreprise avec laquelle je travaille tient un discours aux antipodes du tien :)
Après qui a raison ? Je ne sais pas, mais toujours est-il que ce n’est pas une petite boîte ;)
Et puis médiocre moyenne … c’est pourtant dingue ce qu’on peut faire avec un framework comme react
Cé dépend de tellement de choses ! Ne serait-ce que des développeurs disponibles au moment du projet (le marché étant tendu). Sont-ils plutôt développeurs web/front ou natifs ? Mais aussi, est-ce que l'appli aura beaucoup besoin des couches basses (matériel ou accélération graphique) ? Est-ce que l'appli aura plutôt un look-and-feel personnalisé et égal entre Android et iOS, ou respectera t'elle les canons de chaque plateforme ? Est-ce que les performances sont importantes ?
Chaque réponse peut orienter vers l'une ou l'autre des solutions.
@Dimemas
« mais l’entreprise avec laquelle je travaille tient un discours aux antipodes du tien :) »
Et celle pour qui je travaille valide les propos de @Thms… (c’est aussi une grosse structure)
En fait, chaque entreprise fait comme elle l’entend, en fonction de ses priorités. Et, comme le dit @PetrusM, celles-ci peuvent être diverses et variées, voir contradictoires ! Ce que je peux par contre certifier, c’est qu’en tant qu’utilisateur, je dégage toute app qui a un look’n feel Android. Et même une app qui n’est pas « androidisée » mais qui a une UI/UX trop différent de ce que propose iOS peut suivre le même chemin…
@Thms
"Ça vaut maintenant + le coup de faire plusieurs applications natives excellentes."
Certes, j’ai changé de métier depuis une petite poignée d’années, mais je dois encore rencontrer la moindre entreprise dans ma région qui préfère travailler plus pour produire la même fonctionnalité alors qu’elle n’est pas contrainte de le faire.
Mais peut-être parles-tu de sous-traitants indiens ?
Qu'il y ait besoin d'un développeur Android ET d'un développeur iOS quand on fait du Swift n'a rien à voir avec sa complexité, c'est tout simplement qu'on ne peut PAS développer en Swift pour Android. Il faut donc une personne qui maîtrise également un langage permettant de développer pour Android (exemple : Kotlin).
(Au passage, je développe actuellement pour Android comme pour iOS, que ce soit avec Kotlin et Swift, comme avec Xamarin et Flutter.)
Et donc pour l'avoir pratiqué, non Swift n'est pas spécialement complexe (surtout par rapport aux langages plus anciens), et permet d'éviter bon nombre d'erreurs.
L'utilisation de PWA ou d'autres technologies web (React Native) est à mon avis une erreur actuellement, en particulier au niveau des ressources nécessaires (on intègre un navigateur entier dans toutes les apps, même la plus simple), qui consomme un max de RAM et de place. Et je ne parle pas du Javascript qui est une bouse intersidérale que je conchie particulièrement. (Désolé, c'est mon avis personnel, et ma colère à son encontre a tendance à déborder). Et encore, le jeu actuel est de rajouter des couches supplémentaires pour parer aux problèmes et incomplétudes du truc.
Flutter/Dart en revanche me semble plus raisonnable dans ce domaine, et est assez simple d'approche.
Cependant, tout n'est pas possible avec ces technos multiplateformes, et dans beaucoup de cas, un peu de natif est au rendez-vous (en particulier pour l'accès à des fonctions récentes ou proches du matériel).
J’entends ! ;)
Ça m’est arrivé de pester sur certaines fonctions compliquées à mettre en place via react, rien de handicapant mais il y a eu pas mal de changements dans le bon sens.
Je trouve même que c’est lié à la fermeture de iOS parfois
Après rien ne vaut du natif mais ça reste pour des grosses boites à mon sens
Par exemple l’utilisation du guard est effectivement quelque chose de plus simple que certaines vérifications avec des conditions ennuyeuses parfois et complexes
@ Dimemas : « parce qu'il est ... complexe, chronophage et tellement dur à apprendre que lorsque tu dois travailler sur un projet d'appli pour android et iOS, tu dois avoir besoin d'un dev iOs et dev Android. »
Pourquoi ne pas juste prendre un développeur qui sait faire les deux ?
Si le développement pour Android est si simple par rapport au développement en Swift pour iOS, ça devrait être facile pour un développeur maîtrisant déjà ce dernier de se mettre aussi à Android +Java/Kotlin.
À moins qu’en fait il n’y ait pas tellement de différence de complexité entre les deux… 😉
@BeePotato
> Pourquoi ne pas juste prendre un développeur qui sait faire les deux ?
Parce que c'est plus rare, donc plus cher.
@ byte_order : « Parce que c'est plus rare, donc plus cher. »
Plus cher que deux développeurs ? Non.
Surtout si on s’en tient à son raisonnement, dont je soulignais la faiblesse : si Swift est tellement « complexe, chronophage » qu’un développeur Android ne peut pas s’y mettre (alors qu’il a bien réussi à apprendre Java/Kotlin + les frameworks d’Android), alors on peut supposer qu’un développeur iOS, après avoir réussi à maîtriser une telle complexité, n’aura pas grand mal à faire en plus du Java/Kotlin pour Android.
Sinon, ça signifie qu’il n’y a pas tellement de différence de complexité.
@BeePotato
> Plus cher que deux développeurs ? Non.
Mais un developpeur dual stack n'est dispo que 24h par journée, tandis que 2 développeurs, eux, le sont tout pareil *mais* en même temps.
> on peut supposer qu’un développeur iOS, après avoir réussi à maîtriser une telle
> complexité, n’aura pas grand mal à faire en plus du Java/Kotlin pour Android.
Cela n'a rien à voir avec le langage, qui d'ailleurs n'influence peu au final.
Ce qui compte c'est le niveau de connaissance des frameworks, API, outils et autres piles technologiques qu'une plateforme supporte ou, pire, impose pour développer des trucs dessus.
Chaque individu n'ayant que 24h par jour, de facto devoir maitriser 2 plateformes lui consommera fatalement plus de temps qu'une seule. Probablement pas le double de temps, mais fatalement *plus* de temps.
Ce qui le rend donc plus rare, et donc plus cher.
Y'a pas de magie.
@ byte_order : « Mais un developpeur dual stack n'est dispo que 24h par journée, tandis que 2 développeurs, eux, le sont tout pareil *mais* en même temps. »
C’est pas faux, j’avais un peu oublié ce détail ! 😁
Cela dit, ça ne semblait pas perturber Dimemas, puisqu’il regrettait d’avoir à embaucher deux développeurs au lieu d’un seul.
« Cela n'a rien à voir avec le langage, qui d'ailleurs n'influence peu au final. »
Je le sais bien.
Je rappelle que je répondais de manière sarcastique à Dimemas, qui prétendait le contraire en nous expliquant que la complexité de Swift imposait d’embaucher un développeur supplémentaire juste pour ça.
« Ce qui le rend donc plus rare, et donc plus cher. »
Certes, mais tout de même moins cher que deux développeurs. Y a pas de magie.
@BeePotato
"Pourquoi ne pas juste prendre un développeur qui sait faire les deux ?"
Parce que je facturais mes services 50% plus cher lorsque les deux plateformes étaient demandées. Sachant faire les deux avec excellence et la demande existante, sachant que peu de collègues pouvaient prétendre à la même proficience, il était absolument normal de facturer la valeur supérieure proposée un prix plus élevé.
Prix et rareté. Deux raisons de ne pas juste prendre.
@ fte : « Parce que je facturais mes services 50% plus cher lorsque les deux plateformes étaient demandées. »
Ce qui fait donc 25 % de moins que deux développeurs (ce qui, selon Dimemas, était la solution obligatoire à laquelle vers laquelle on se retrouvait forcé de se diriger à cause de la grande complexité de Swift).
« Prix et rareté. Deux raisons de ne pas juste prendre. »
Le prix, non, par rapport au fait de prendre deux développeurs (dans cette branche de la conversation, on n’est pas en train de comparer à une solution différente à base de développement unique multi-plateformes, qui coûterait effectivement moins cher).
Quant à la rareté, elle n’est pas une raison de décider de ne pas prendre un tel développeur. Juste une contrainte qui fait qu’on n’en a parfois pas la possibilité, faute d’en trouver un.
Parfois, parce que bon, ça n’est pas non plus un cas si rare que ça, le gusse qui sait développer à la fois pour iOS et Android. On ne parle pas de trouver un chercheur en pointe dans un domaine super compliqué, mais juste de développer des applis pour de fichus smartphones. 😉
@ PetrusM
> je ne comprends pas la complexité que vous reprochez à Swift
Ça par exemple.
En ne regardant que la 2nde ligne, je vous mets au défit de dire avec certitude quel le type de données de typeName ou de $0 ci-dessous.
Quand on doit utiliser en Swift des données venant de code en C, voila le genre de délire que ça donne.
public var fstypename: String {
let typeName = withUnsafePointer(to: f_fstypename) {
$0.withMemoryRebound(to: UInt8.self, capacity: MemoryLayout.size(ofValue: $0)) {
String(cString: $0)
}
}
return typeName
}
Tout ça juste pour récupérer en Swift une chaîne en C (null terminated). Non mais allô quoi !
Le type qui a développé Swift et qui a vite abandonné le navire a dû oublier qu'Unix était écrit essentiellement en C.
Sans parler de toutes ces variables dont le type n'est pas écrit dans le code, parce que Xcode et le compilateur peuvent le déduire du contexte. On me dit, tu peux faire un cmd-click sur le code dans Xcode. Sauf que dans les Pull Request affichés dans un navigateur, je n'ai pas de compilateur dans ma tête qui connaitrait 100% du code.
Ah oui, je reconnais qu'à l'interface avec du C (et récemment du C++ paraît-il, mais je n'ai pas encore regardé), c'est assez velu. Mais c'est la rançon de pouvoir passer du code non managé à la sécurité du Swift, très clairement... Après, rien n'empêche d'écrire un morceau en C également, si c'est pour réduire l'interface Swift/C.
J'ai récemment dû interfacer du Kotlin/Java avec du C++ via Swig....🤢 Ne faites pas ça chez vous. Je crois que de toutes façons, à l'interface entre les langages, c'est compliqué.
De plus, si vous n'aimez pas le typage implicite, rien ne vous empêche de mettre une règle de codage obligeant le typage explicite (et même une option du compilateur serait bienvenue).
De la même façon, dans votre code, $0 est du sucre pour ne pas écrire explicitement le type de la variable : {variableName: UnsafePointer -> variableName.with...}
Il y a pas mal de choses que l'on peut rendre implicite, mais il faut le faire à bon escient pour garder la compréhension du code.
> Mais c'est la rançon de pouvoir passer du code non managé à la sécurité du Swift,
C'est quoi du code "managé" ?
Quoiqu'il en soit, il suffit de mettre un ! au mauvais endroit pour faire planter le code.
Chez nous, c'est "interdit".
Mais on trouve quand même pas mal de ?
Donc c'est cool, si la var vaut nil, ça fait rien, comme en Objective-C, et si "ne rien faire" c'est ok ou pas dans le contexte, ce n'est certainement pas Swift qui le dira.
Donc on a du code "pas safe", et Swift ne change rien en cela.
Quant aux trucs du genre :
let sortedNames = names.sorted(by: >)
si cet exemple vous semble clair, remplacez pour voir "names.sorted" par du code écrit par un collègue qui maîtrise mal l'anglais et définit des noms de fonctions en "franglais", et ce sera beaucoup moins clair.
J'ai mal utilisé "managé" qui est en fait une terminologie Microsoft. Ce que je voulais indiquer, c'est du code protégé, et qui vérifie ce qu'il écrit dans la mémoire, et ne peut donc (en théorie toujours) la corrompre. En C par exemple, on peut écrire ce qu'on veut au pointeur que l'on veut. Par exemple écrire plus loin qu'une taille de tableau. En Swift, ce n'est pas possible (ou du moins, ça va planter sans écrire quelquechose on-ne-sait-où).
Effectivement, en Swift, utiliser ! est une mauvaise pratique. Il n'est quasiment jamais absolument nécessaire (on utilise généralement plutôt guard let). Les ? indiquent simplement l'absence d'objet. Et ce que l'on fait en cas d'absence d'objet doit donc forcément être explicitement indiqué, sinon ça ne compile pas (contrairement à d'autres langages, où l'absence d'objet est possible mais non explicite, et quand on tombe sur une alors que ce n'est pas prévu, ça plante en NullObjectException).
Du coup, je ne comprends pas "si la var vaut nil, ça fait rien". Oui, une variable avec un ? peut être nil, et on ne pourra pas ignorer ce fait. Bien évidemment, il faut réserver les ? aux variables qui peuvent effectivement être nil pour une bonne raison.
@ marc_os : « Donc c'est cool, si la var vaut nil, ça fait rien, comme en Objective-C »
Euh… non.
« Quant aux trucs du genre :
let sortedNames = names.sorted(by: >)
si cet exemple vous semble clair, remplacez pour voir "names.sorted" par du code écrit par un collègue qui maîtrise mal l'anglais et définit des noms de fonctions en "franglais", et ce sera beaucoup moins clair. »
C’est là un problème de mauvais développeur et non de langage. Il faudrait être de très mauvaise foi pour affirmer que ce type de problème se pose moins avec ce code :
NSArray *sortedNames = [names sortedArrayUsingSelector: @selector(compare:)];
Les noms plus longs en Objective C posent tout autant de difficultés aux non anglophones. Je doute que le collègue en question arrive à pondre une telle API en Objective C plus facilement que sa version Swift.
@ BeePotato
> Les noms plus longs en Objective C posent tout autant de difficultés aux non anglophones.
Pour moi cela relève de la faute professionnelle.
Un dev doit maîtriser l'anglais un minimum.
Sinon, ils n'ont qu'à utiliser Windev dont le langage de programmation est traduit en français ! 🤪
@ marc_os : « Pour moi cela relève de la faute professionnelle.
Un dev doit maîtriser l'anglais un minimum. »
Merci de confirmer que c’est bien un problème lié au développeur et non au langage. À moins que ça ne relève de la faute professionnelle que si on a du mal à nommer ses méthodes en Objective C, mais pas quand c’est en Swift ? 😉
@ PetrusM
> si vous n'aimez pas le typage implicite, rien ne vous empêche de mettre une règle de codage obligeant le typage explicite
Rien ?
Si, quelqu'un :
Notre directeur technique qui impose ses règles de développement.
Alors, c'est encore un problème côté dev, pas côté langage !
C'est une question d'équilibre entre verbosité, lisibilité, et goût personnel... Le langage en tous cas, permet les deux.
@ marc_os : « En ne regardant que la 2nde ligne, je vous mets au défit de dire avec certitude quel le type de données de typeName ou de $0 ci-dessous. »
Mais pourquoi se forcerait-on à ne regarder que cette deuxième ligne alors que le contexte proche indique clairement ce qui est fait et avec quels types de données ? 🙄
D’autre part, même si on voulait se lancer ce défi, on devinerait assez facilement qu’une variable nommée typeName sera fort probablement du type String (ou au moins d’un type adoptant StringProtocol).
« Quand on doit utiliser en Swift des données venant de code en C, voila le genre de délire que ça donne. »
Que ça donne parfois. Il s’agit tout de même là d’un cas assez particulier.
« Tout ça juste pour récupérer en Swift une chaîne en C (null terminated). Non mais allô quoi ! »
Attention : les gens ne connaissant pas Swift risqueraient de croire que ça se passe comme ça pour toutes les chaînes C, alors que c’est faux. Ce serait dommage. 🙂
Ce code-là (qui mériterait effectivement de bénéficier d’un raccourci plus pratique), c’est uniquement pour gérer le cas d’un tableau de char statique. Pour la plupart des chaînes, plutôt de type char*, on se contente d’un simple :
let typeName = String(cString: typename_venu_du_C)
@ BeePotato
> Mais pourquoi se forcerait-on à ne regarder que cette deuxième ligne alors que le contexte proche indique clairement ce qui est fait et avec quels types de données ?
Justement, on n'a pas toujours le contexte, et certainement pas quand le code est affiché dans une page web dans le cadre d'un Pull Request qui par défaut n'affiche que les modifications. Aucune aide contextuelle de Xcode n'est disponible. On peut juste perdre du temps (car il faut chercher l'information) en demandant au site d'afficher le fichier en entier pour pouvoir l'analyser.
> on devinerait assez facilement qu’une variable nommée typeName
Evidemment !
Mais d'une part pour cela il faut que les variables soit nommées correctement, car la plupart des dev français maitrisant mal l'anglais, ils ont tendance à traduire littéralement, et "nom du type", ça peut donner "nameType".
Si vous rencontrez "var nameType = ...", que déduirez vous du type de la var "nameType" ?
Cet exemple peut paraître trivial parce qu'il est trivial.
Si le l'ai donné, c'est à titre... d'exemple.
Car la difficulté c'est quand le même schéma est utilisé mais avec des noms de var en franglais et/ou avec des fonctions et des types définis dans le projet et dont on ne peut pas dire intuitivement : "la var 'userCategory' a tel type" de la même manière qu'on peut dire intuitivement 'typeName' est (probablement) de type String.
Notez, que l'intuition, et les peut-être sont une voie royale pour la création bogues.
@ marc_os : « Justement, on n'a pas toujours le contexte, et certainement pas quand le code est affiché dans une page web dans le cadre d'un Pull Request qui par défaut n'affiche que les modifications. »
« Certainement pas » ? Étrange. La plupart du temps, et notamment sur GitHub, je vois bien chaque modification affichée avec quelques lignes au-dessus et en-dessous, afin d’avoir une petite idée du contexte. On n’utilise peut-être pas les même outils. Quoi qu’il en soit, ce « certainement pas » est faux.
« Mais d'une part pour cela il faut que les variables soit nommées correctement, car la plupart des dev français maitrisant mal l'anglais, ils ont tendance à traduire littéralement, et "nom du type", ça peut donner "nameType".
Si vous rencontrez "var nameType = ...", que déduirez vous du type de la var "nameType" ? »
Notons qu’avec un NSString *nameType, je connais effectivement le type déclaré (qui peut être faux) de cette variable, mais je n’en conclus pas grand chose de plus au sujet de sa sémantique — qui est la vraie information qui m’intéresse (le type n’étant qu’un outil au service de cette sémantique).
« Car la difficulté c'est quand le même schéma est utilisé mais avec des noms de var en franglais »
Ça, encore une fois, ce n’est pas un problème de langage.
« avec des fonctions et des types définis dans le projet et dont on ne peut pas dire intuitivement : "la var 'userCategory' a tel type" de la même manière qu'on peut dire intuitivement 'typeName' est (probablement) de type String. »
Notons que si on ne connaît pas suffisamment bien le projet pour savoir quel type devrait avoir une variable userCategory déclarée à cet endroit, on ne devrait peut-être pas s’occuper d’essayer de valider les PR des autres. 😛
« Notez, que l'intuition, et les peut-être sont une voie royale pour la création bogues. »
En effet. Tout en étant des outils nécessaires pour le débugage et pour tenter de comprendre le code d’autrui.
Notons aussi que se fier à un type déclaré juste parce qu’il est là, dans un langage où on peut si facilement se trouver à affecter un objet d’un type A à variable déclarée comme pointant vers un type B qui n’a rien à voir, le tout sans déclencher le moindre warning, c’est aussi un des pavés constituant le revêtement de cette voie royale vers le bug. 😉
@ marc_os : en général ça se fait ailleurs
@PetrusM
"que Swift par rapport à ObjC"
Bof. C’est pas tellement différent en fait. On est pas à comparer C et Haskell non plus.
On peut toujours opter pour ObjC++ aussi. L’avantage présumé de Swift devient encore plus présumé.
Présumer enfin de la présumée supériorité d’un langage de configuration par rapport à d’autres langages de configuration, ce que n’est par ailleurs pas JSON, en se basant sur la présumée supériorité d’un langage de programmation par rapport à d’autres langages de programmation fort peu différents au fond me semble présumer beaucoup.
Ce n’est au final qu’un nième truc propriétaire d’Apple.
@ fte : « Ce n’est au final qu’un nième truc propriétaire d’Apple. »
Soyons précis : un nième truc propriétaire opensource d’Apple.
C’est un détail qui peut avoir son importance, si des gens se mettent à s’intéresser à ce truc (ce qui ne me semble tout de même pas très probable, mais je peux tout à fait me tromper).
@BeePotato
"C’est un détail qui peut avoir son importance"
Tu as raison, c’est juste.
J’ai le sentiment que c’est exactement la même syntaxe que le hcl
Tiens, on y trouve quelque chose que vous allez adorer chez macg.
Des fichiers .adoc au format "AsciiDoc" pour les Readme, un "concurrent" au Markdown...
— Pourquoi encore un autre format ?
— Pourquoi pas.
...
formidable... avant j'avais 4 langages à la gomme pour générer des configurations à connaître, maintenant j'en ai 5 !
"framework de constructions de langages Truffle,"
holala
"compilateur Java de la distribution GraalVM,"
HOLALALA !!
"Apple dit avoir voulu concevoir un langage qui « détecte les erreurs de validation avant le déploiement », s’adapte « aux cas d’usage les plus simples comme les plus complexes » et surtout est « un plaisir à écrire grâce à nos excellentes intégrations aux IDE »"
oulaaaaaaaaaaa
j'ai arrêté à nos excellentes intégrations aux IDE...
en gros apple a créé le JSON écrit comme du python... whoah ... 🤦🏽♂️
alors que tout le monde se satisfait du JSON pour sa simplicité et sa souplesse avec les différents langages
@Dimemas
Perso je n’écris pas de JSON, mais du Yaml.
Le json est pour les machines.
@Sgt. Pepper
{
"X":123,
"Y":678,
"T":[1,2,56]
}
Je suis une machine 😜
@koko256
😂 👍
@Sgt. Pepper
Rien de tel qu’un bon petit flames war.
Et comme on ne peut pas faire éternellement du vimacs (Vim-improved Emacs, rien que pour raviver la flamme…) je propose de jeter une pierre dans le jardin de YAML :
https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell
Pages