Craig Federighi : Apple n'a pas enterré les scripts dans macOS
Les scripts et l’automation ont un avenir chez Apple. Après le départ visiblement forcé de Sal Soghoian, à qui l’on doit la plupart des outils permettant de créer et d’utiliser des scripts sur macOS, l’inquiétude est forte chez les amateurs d’AppleScript, d’Automator et consorts. Et il est vrai que Soghoian a laissé fortement penser que l’avenir de cette pratique était compromise du côté de Cupertino.
Un lecteur de 9to5Mac a demandé à Craig Federighi quelle était la position d’Apple après que l’entreprise eut montré la porte de sortie à ce vieux routier du Mac. Le vice président en charge du logiciel a pris le temps de répondre et surtout, de rassurer :
C’est assurément une bonne nouvelle, même si Apple concentre ses ressources sur Swift plutôt que sur ses outils de scripts. Automator, lancé avec Mac OS X 10.4, a reçu très peu de mises à jour depuis, et il n’existe pas de solution « maison » de script pour iOS (on peut en passer par des applications tierces comme Workflow).
L’avenir semble de toutes manières briller plus du côté de Swift, dont Apple assure une grosse promotion. Des ateliers Heure de Code autour du langage de programmation vont être organisés début décembre dans les Apple Store.
En même temps, Craig allait pas répondre : "fuck off"
Pour moi macOS s'éteint doucement
"En même temps, Craig allait pas répondre : "fuck off""
Il n'aurait pas répondu.
Ce qu'il faut comprendre, c'est que le départ de Sal Soghoian n'est pas lié à la disparition de l'automatisation de Mac OS X
Mais donc il reste pas mal de possibilités.
J'en vois essentiellement deux :
- Refus de Sal Soghoian à passer à Swift plutôt qu'AS ?
- Problème de personne entre un nouveau manager et Sal Soghoian ?
Quoi qu'il en soit, soit AS reste avec automator (cool) soit Apple a dans ses cartons un truc génial bien plus cool et ouvert, plus standard, plus simple à mettre en place etc... (super cool)
Pas de quoi pleurer donc.
Ben en fait, non AS et Automator ne sont pas geniaux du tout et posent de nombreux problemes.
Je vais pasrevenir sur la syntaxe et la logique bizare d'AS, il y a une partie subjective et on peut s'y faire si on fait que ça.
Le probleme c'est l'inconsistance et la difficulté de mise en oeuvre.
Un systeme de scripting, d'automatisation, implique de pouvoir controler les composants (applications, services, extensions,...) selon un protocole standard et systematique. Ça veut dire que n'importe quelle application doit etre pilotable de la meme maniere.
Avec Automator et AppleScript c'est pas du tout le cas.
Il faut que les applications soient prevues et programmées specifiquement pour repondre a Applescript. C'est pas universel ni automatique, beaucoup d'applications ne sont simplement pas scriptables.
Le probleme est encore plus gros avec Automator, puisque il faut que des modules soient fournis par l'editeur pour remplir des taches specifiques et limités: impossible d'acceder a des fonctions non prevues.
Et c'est un tres gros probleme, le principe du scripting etant justement de permetre un usage non couvert par une fonction du logiciel.
Je prends un exemple simple: une excellente application, tres bien programmée, activement développée et tres fonctionnelle, PixelMator, n'est pas scriptable.
Impossible d'automatiser la generation de fichiers a partir de layer, et avec un nom normalisé. C'est un traitement tout ce qu'il y a de plus automatisable et qui est contre productif de faire a la main, et pourtant c'est pas possible, parce que l'application n'est pas scriptable.
On peut reprocher aux editeurs de ne pas concevoir l'application pour etre scriptable, mais en vérité le problème vient de MacOS: si le systeme de scripting etait consistant les logiciels seraient automatiquement scriptable, au moins pour les fonctions de base. Non, il faut developper spécifiquement.
@C1rc3@0rc
Tu décris de nombreux problèmes liés aux limites d'Automator. Cela ne signifie en rien qu'Automator n'est pas génial. C'est tout le challenge proposé aux développeurs d'applications. Il faut qu'ils les rendent modulaires et scriptables.
Sous Windows, il n'y a pas d'équivalent à Automator et tu dois tout faire à la main. Tu dois répéter les mêmes actions manuelles des centaines de fois !!!
Laisse-moi te donner un exemple de processus Automator que j'avais réalisé et qui m'avait vraiment facilité la vie.
Contexte :
J'avais besoin de me constituer une bibliothèque d'images. Si tu lances Bing (le moteur de recherche de Microsoft), chaque jour il y a une nouvelle image. J'avais trouvé un site où il y en avait des centaines de toutes sortes.
Sous Windows pour récupérer les images tu fais clic droit puis enregistrer sous... et tu répètes des centaines de fois la même manip ! Tu y passes un temps fou !
Avec Automator, tu lui donnes l'URL puis il y a une action Safari pour récupérer les images de la page (en fait il scrute les balises HTML img).
Automator, les récupère dans un dossier de ton choix. Ensuite, j'enchainais par un redimensionnement des images pour qu'elles aient toutes les mêmes dimensions et enfin par un renommage avec un préfixe particulier.
Pour récupérer des centaines d'images et les reformater, avec Automator ça te prend entre 5 à 15 minutes et tu ne te fatigues pas.
Essaie de faire ça avec le système de Microsoft. Tu m'en diras des nouvelles...
Cool non !
Et si tu fais ça avec un outil comme Selenium, tu passes moins de temps à créer ton script, non ?
Et cerise sur le gâteau, il est multiplateforme !
Cool
@Un Vrai Type
Tu n'as rien compris. Selenium ne permet que de faire des traitements Web. Automator fait des tas de choses !
Pour quelqu'un comme moi qui a l'habitude d'utiliser Automator, le workflow pour récupérer des images, les redimensionner et les renommer ne prend que 5 minutes à écrire et à tester !
Je ne vois pas comment tu peux dire que l'on passe du temps à créer des workflows avec Automator. C'est juste que tu ne l'utilises pas !
Selenium ne peut pas te réveiller le matin et lancer iTunes !
Donc tu n'as rien compris à l'éventail des possibilités d'Automator !
Pour faire tout ce que Automator est capable de faire, sous Windows il te faut combien de logiciels spécifiques pour traiter une tâche particulière ?
Sors-moi la liste de toutes les applis dont tu as besoin sous Windows pour faire l'équivalent de tout ce que Automator peut faire !
Automator est pré-installé sur Mac.
Hi hi hi !!!!!
@Un Vrai Type
Pour enfoncer un peu plus le clou et pour te montrer que tu n'as rien compris aux possibilités d'Automator voici la suite du traitement que j'avais réalisé :
Une fois les images récupérées, redimensionnées et renommées, je créais un dossier compressé que j'envoyais via FTP sur un serveur (toujours avec Automator). Ensuite un autre processus Automator lié au dossier (processus action sur dossier) sur le serveur de récupération, décompressait l'archive et copiait les images dans un dossier d'images d'un site web destinataire des images.
Les images étaient ensuite disponibles dans mes pages web.
Mais le dossier compressé tu peux aussi l'envoyer par Mail avec Automator au lieu de l'envoyer par FTP. Etc, etc, etc...
Tu peux toujours essayer de faire tout ça avec Selenium, tu m'en diras des nouvelles !...
Hi hi hi
@ C1rc3@0rc : « la logique bizare d’AS »
La logique est pourtant très classique et la même qu’on trouve dans la plupart des langages les plus connus.
« on peut s'y faire si on fait que ça. »
Même si on ne fait pas que ça, d’ailleurs.
« Et c'est un tres gros probleme, le principe du scripting etant justement de permetre un usage non couvert par une fonction du logiciel. »
Pas vraiment. Le principe des scripts, c’est de combiner les fonctions des logiciels de la façon qu’on veut.
« On peut reprocher aux editeurs de ne pas concevoir l'application pour etre scriptable, mais en vérité le problème vient de MacOS: si le systeme de scripting etait consistant les logiciels seraient automatiquement scriptable, au moins pour les fonctions de base. »
Ce passage-là est juste du grand n’importe quoi. J’ai du mal à voir comment on arriverait à des logiciels scriptables automatiquement sans aucun effort à fournir de la part de leurs développeurs.
«Mais donc il reste pas mal de possibilités.
J'en vois essentiellement deux :
- Refus de Sal Soghoian à passer à Swift plutôt qu'AS ?
- Problème de personne entre un nouveau manager et Sal Soghoian ?
»
On ne vire pas un architecte logiciel pour un conflit avec un manager, ou alors c'est que la societe est suicidaire. On vire plutot le manager...
Ajouter Swift au langages de controle du scripting est quelque chose de relativement simple et c'est une option qui ne signifie pas degager AS. On peut utiliser Javascript a la place d'AS.
Donc ces possibilités semblent improbables comme cause du depart de Soghoian.
Jusqu'a present les "départs" de personnes clés se sont fait sur des questions de pouvoir (conflit avec Ive principalement) ou des reorientations d'architecture en profondeur, voire suppression de fonctionnalité.
Comme je le dis precedemment, l'automatisation sur MacOS est loin d'etre une reussite, et c'est d'autant plus grave qu'on est sur une base Unix qui est conceptuelement construite pour l'automatisation. Il y a donc une rupture de la logique du systeme a un tres haut niveau.
Se pose le probleme de la securité.
On voit que depuis quelques annees Apple s'oriente sur une voie securitaire construite sur la restriction et la fermeture. Et c'est pas une reussite.
Le scripting, s'il est mal fait, ouvre des breches dans la securité, on le voit bien sur Windows avec des virus qui exploitent le Basic dans Office par exemple.
Apple a choisi d'interdire le scripting dans iOS. Pourtant iOS c'est 95% MacOS.
Automator implique de rajouter des modules dans le systeme qui exploitent les fonctionnalité des applications... Cela est contraire a la logique de SIP par exemple.
Pendant des annees MacOS a ete fourni avec Python et Ruby, principaux langages de scripting, et auquel Apple avait contribué a l'integration. Ce n'est plus le cas.
Donc cela fait beaucoup d'elements qui sont de mauvaise augure pour le scripting sur MacOS
@C1rc3@0rc
"ou alors c'est que la societe est suicidaire" ??
C'était un homme clef dont dépendait une grande part de l'avenir économique de l'entreprise? ?
@C1rc3@0rc
A oui tu considères bien le mec comme une ressource clef ?
C’est vraiment ton truc la SF ??
@C1rc3@0rc
"Pourtant iOS c'est 95% MacOS"
Une de tes connerie favorite ?
"On ne vire pas un architecte logiciel pour un conflit avec un manager, ou alors c'est que la societe est suicidaire. On vire plutot le manager..."
Non seulement ça a été la politique de Microsoft pour Internet Explorer (ce qui explique de la version 7 n'est pas une évolution de la version 6 qui n'est pas une évolution de la version 5, mais la version 7 contient les moteurs de rendus des versions antérieures : Les managers sont les mêmes, les ingénieurs ont changés) mais en plus, je vois EXACTEMENT la même situation en ce moment chez un client.
Il faut bien comprendre que les décideurs n'entendent pas les petites gens. Si une personne bien placée peut dire à T.Cook "Soghoian il est méchant avec moi, il m'empêche de faire des trucs géniaux", Soghoian lui ne peut pas se défendre, et ne sera entendu que par les RH qui auront déjà l'instruction de le débarquer.
Voilà la réalité d'entreprise.
@ C1rc3@0rc : « et c'est d'autant plus grave qu'on est sur une base Unix qui est conceptuelement construite pour l'automatisation. Il y a donc une rupture de la logique du systeme a un tres haut niveau. »
Ça aussi, c’est n’importe quoi.
« Automator implique de rajouter des modules dans le systeme qui exploitent les fonctionnalité des applications... »
Non.
« Cela est contraire a la logique de SIP »
Non plus.
Cette réponse tend à confirmer l'hypothèse du développement de nouveaux outils d'automation, plus modernes. ?
Automator c'est cool ?, mais il y a surement moyen de faire encore mieux ! ☝️
@patrick86
Pas impossible que le départ soit motivé par un conflit autour de l'avenir de cette démarche sur macOS non pas en terme d'abandon mais de redéfinition de l'approche sur des bases plus modernes ?
Sur un divorce il est toujours dangereux de ne se fier qu'à un son de cloches ?
@awk
En parlant de cloche...
@mctos
Bravo, quel prodigieux sens de la répartie ?
@awk
C'est sa façon de raisonner à lui.
@Bigdidou
?
Super! Maintenant on attend les réponses de Mr Langue-de-bois (Schiller) sur:
1. Origine des problèmes graphiques/ssd des nouveaux MBP
2. Pourquoi un prix si élevé?
3. À quand le renouvellement du Mac Pro et Mac Mini?
4. Pourquoi le nouveau MBP est fourni sans chiffon et cordon d'alimentation?
...
@mat 1696
tu t'es trompé de news manifestement.
Pourquoi un prix si élevé ? parce que :
le processeur est nouveau et plus cher
le SSD est nouveau extrêmement performant et plus cher
le tracpad est beaucoup plus grand et plus cher
quatre connecteurs sont multifonctions avec des contrôleurs plus complexes et beaucoup plus chers que de simples USB A
les hauts parleurs sont nouveaux plus performants et plus chers
il y a un processeur en plus pour le touch id et un processeur n'est pas gratuit
il y a un nouveau processeur pour le touch bar et un processeur ce n'est pas gratuit
il y a un touch bar Oled qui est infiniment plus cher que les touches fonctions
il il a le lecteur du touch id qui n'est pas gratuit
parce qu'il a fallu développer deux ans pour le nouveau touch bar (un nouvel OS), la nouvelle carte mère, le corps du macbook, les nouvelles intégrations, le nouveau clavier etc et 2 ans de R&D avec des centaines d'ingénieurs, le prototype etc ce n'est pas gratuit
etc. Je suppose que vous vous travaillez gratuitement et que les matériaux que vous utilisez quand vous bricolez vous sont offerts par Leroy Merlin
pour votre 4 vous inventez, il est vrai que le titre de MacGe était mensonger. Le cordon d'alimentation y est bien, c'est la rallonge qui n'y est plus, pas plus qu'elle n'y est pour les iPad et autres iPhone qui n'ont pas non plus de mac safe ce qui n'en secoue pas une aux utilisateurs comme dirait Mac Ge et qui pourtant ont infiniment plus de risques de se faire valdinguer qu'un macbook.
@Malum
Pas le bon sujet, pas le bon forum, pas le bon argumentaire...
Pages