Swift, Objective-C, C++, Kotlin et Java sont dans un bateau...

2

Réponses

  • devulderdevulder Membre
    mars 2019 modifié #32

    @klog a dit :

    @Céroce a dit :

    Franchement, qu'est-ce qui empêche techniquement Apple de faire avec Swift ce qu'elle a fait avec Objective-C, en permettant une certaine interopérabilité de C++ dans du code Swift ? À mon avis rien...

    Et le manque de temps et d'ingénieurs assez qualifiés, ça ne compte pas ?
    Tu n'as aucune idée de la difficulté de la tâche.

    Bien entendu, contrairement à toi, j'en sais absolument rien... :/

    Rien que la gestion mémoire (ou plutôt son absence) en C++ rend l'interopérabilité avec Swift très difficile.

    Ils l'ont bien fait il y a 10 ans avec Objective-C et ARC, totalement compatibles avec C++... Et il n'est même pas nécessaire qu'ils permettent l'inclusion de code C++ directement à l'intérieur de code Swift. Simplement que soit possible l'import de modules C++, l'allocation d'objets C++, et leurs utilisations en Swift, en suivant la syntaxe Swift s'il le faut. Rendre compatibles des langages de programmation n'a rien d'extraordinaire, et c'est pratiqué depuis des lustres...

    Il s'agit vraisemblablement d'une restriction volontaire, dont l'objet est peut-être de maintenir captifs les développeurs iOS.

    Oui, il s'agit d'une restriction volontaire, mais il n'y a pas besoin d'explications complotistes.

    J'ai bien précisé "peut-être"... Loin de moi toute idée "complotistes"... Que tu mésestimes mes compétences, passe encore, mais pour le coup je te trouve un poil agressif... Mon avis vaut le tien, et on peut ne pas être d'accord sans disqualifier ou méjuger son interlocuteur.

    Les ingés d'Apple doivent se fixer des priorités. La stabilité des ABI qui arrive seulement avec Swift 5 aura certainement beaucoup plus d'impact pour la plupart des programmeurs Swift que l'interopérabilité avec C++ (qui n'est pas impossible, mais qui oblige à passer par Objective-C).

    Je radote, mais je t'invite à écrire une passerelle C++/Objective-C/Swift pour une bibliothèque de plusieurs dizaines d'objets... Les développeurs ont autres chose à f...aire que de se coltiner de la glue. Tu crois franchement qu'Office, Photoshop, Autocad, Cinéma 4D, Final Cut, sont totalement écris en Objective-C ? Ce qui concerne l'interface l'est certainement, mais le moteur de ces softs, multi-plateforme, est vraisemblablement en C++. Ces boites ne vont pas réécrire des dizaines de millions de lignes de codes en Swift parce qu'il est incompatible avec C++. Je pense qu'elles basculeront peut-être un jour à Swift quand :

    1) Apple leur permettra de faire migrer progressivement leur code (donc en préservant Objective-C)
    2) Apple rendra Swift compatible avec C++.

    En attendant, tant qu'Objective-C++ et sa compatibilité C++ est maintenu, et que je peux continuer à donner mon avis, ça me convient... B)

    le souci avec ton raisonnement c'est qu'Apple va prévenir des années avant les grosses boites en leur disant
    attention Objective-c c'est le fini en 20XX, alors que toi tu vas le savoir uniquement a une WWDC quelques mois avant ! ca craint alors pour tes softs pour faire une transition dans de bonne condition

  • muqaddarmuqaddar Administrateur

    J'ai fait un gros split du sujet sur l'iMac, parce que là, on est vraiment parti sur autre chose... pauvre Rocou.

  • DrakenDraken Membre
    mars 2019 modifié #34

    Swift et Kotlin mangent des sushis sur le bateau, regardant Objective-C, C++ et Java se faire bouffer par les requins ..

  • @devulder a dit :

    @klog a dit :

    @Céroce a dit :

    Franchement, qu'est-ce qui empêche techniquement Apple de faire avec Swift ce qu'elle a fait avec Objective-C, en permettant une certaine interopérabilité de C++ dans du code Swift ? À mon avis rien...

    Et le manque de temps et d'ingénieurs assez qualifiés, ça ne compte pas ?
    Tu n'as aucune idée de la difficulté de la tâche.

    Bien entendu, contrairement à toi, j'en sais absolument rien... :/

    Rien que la gestion mémoire (ou plutôt son absence) en C++ rend l'interopérabilité avec Swift très difficile.

    Ils l'ont bien fait il y a 10 ans avec Objective-C et ARC, totalement compatibles avec C++... Et il n'est même pas nécessaire qu'ils permettent l'inclusion de code C++ directement à l'intérieur de code Swift. Simplement que soit possible l'import de modules C++, l'allocation d'objets C++, et leurs utilisations en Swift, en suivant la syntaxe Swift s'il le faut. Rendre compatibles des langages de programmation n'a rien d'extraordinaire, et c'est pratiqué depuis des lustres...

    Il s'agit vraisemblablement d'une restriction volontaire, dont l'objet est peut-être de maintenir captifs les développeurs iOS.

    Oui, il s'agit d'une restriction volontaire, mais il n'y a pas besoin d'explications complotistes.

    J'ai bien précisé "peut-être"... Loin de moi toute idée "complotistes"... Que tu mésestimes mes compétences, passe encore, mais pour le coup je te trouve un poil agressif... Mon avis vaut le tien, et on peut ne pas être d'accord sans disqualifier ou méjuger son interlocuteur.

    Les ingés d'Apple doivent se fixer des priorités. La stabilité des ABI qui arrive seulement avec Swift 5 aura certainement beaucoup plus d'impact pour la plupart des programmeurs Swift que l'interopérabilité avec C++ (qui n'est pas impossible, mais qui oblige à passer par Objective-C).

    Je radote, mais je t'invite à écrire une passerelle C++/Objective-C/Swift pour une bibliothèque de plusieurs dizaines d'objets... Les développeurs ont autres chose à f...aire que de se coltiner de la glue. Tu crois franchement qu'Office, Photoshop, Autocad, Cinéma 4D, Final Cut, sont totalement écris en Objective-C ? Ce qui concerne l'interface l'est certainement, mais le moteur de ces softs, multi-plateforme, est vraisemblablement en C++. Ces boites ne vont pas réécrire des dizaines de millions de lignes de codes en Swift parce qu'il est incompatible avec C++. Je pense qu'elles basculeront peut-être un jour à Swift quand :

    1) Apple leur permettra de faire migrer progressivement leur code (donc en préservant Objective-C)
    2) Apple rendra Swift compatible avec C++.

    En attendant, tant qu'Objective-C++ et sa compatibilité C++ est maintenu, et que je peux continuer à donner mon avis, ça me convient... B)

    le souci avec ton raisonnement c'est qu'Apple va prévenir des années avant les grosses boites en leur disant
    attention Objective-c c'est le fini en 20XX, alors que toi tu vas le savoir uniquement a une WWDC quelques mois avant ! ca craint alors pour tes softs pour faire une transition dans de bonne condition

    Si Apple doit déprécier Obj-C elle le fera à une WWDC et tout le monde sera au jus en même temps sauf les gros acteurs du marché qui auront été consulté. Mais Apple ne déprécie rien pour le supprimer 2 mois après on est sur des cycles de 2~3 ans voire plus.
    Je ne parle pas de logiciel end-user donc pas la peine de sortir Aperture ou mobile.me. Pas d'inquiétude à avoir. D'autant qu'Obj-C risque plus de devenir désuet que déprécié.

  • klogklog Membre

    @devulder a dit :

    @klog a dit :

    @Céroce a dit :

    Franchement, qu'est-ce qui empêche techniquement Apple de faire avec Swift ce qu'elle a fait avec Objective-C, en permettant une certaine interopérabilité de C++ dans du code Swift ? À mon avis rien...

    Et le manque de temps et d'ingénieurs assez qualifiés, ça ne compte pas ?
    Tu n'as aucune idée de la difficulté de la tâche.

    Bien entendu, contrairement à toi, j'en sais absolument rien... :/

    Rien que la gestion mémoire (ou plutôt son absence) en C++ rend l'interopérabilité avec Swift très difficile.

    Ils l'ont bien fait il y a 10 ans avec Objective-C et ARC, totalement compatibles avec C++... Et il n'est même pas nécessaire qu'ils permettent l'inclusion de code C++ directement à l'intérieur de code Swift. Simplement que soit possible l'import de modules C++, l'allocation d'objets C++, et leurs utilisations en Swift, en suivant la syntaxe Swift s'il le faut. Rendre compatibles des langages de programmation n'a rien d'extraordinaire, et c'est pratiqué depuis des lustres...

    Il s'agit vraisemblablement d'une restriction volontaire, dont l'objet est peut-être de maintenir captifs les développeurs iOS.

    Oui, il s'agit d'une restriction volontaire, mais il n'y a pas besoin d'explications complotistes.

    J'ai bien précisé "peut-être"... Loin de moi toute idée "complotistes"... Que tu mésestimes mes compétences, passe encore, mais pour le coup je te trouve un poil agressif... Mon avis vaut le tien, et on peut ne pas être d'accord sans disqualifier ou méjuger son interlocuteur.

    Les ingés d'Apple doivent se fixer des priorités. La stabilité des ABI qui arrive seulement avec Swift 5 aura certainement beaucoup plus d'impact pour la plupart des programmeurs Swift que l'interopérabilité avec C++ (qui n'est pas impossible, mais qui oblige à passer par Objective-C).

    Je radote, mais je t'invite à écrire une passerelle C++/Objective-C/Swift pour une bibliothèque de plusieurs dizaines d'objets... Les développeurs ont autres chose à f...aire que de se coltiner de la glue. Tu crois franchement qu'Office, Photoshop, Autocad, Cinéma 4D, Final Cut, sont totalement écris en Objective-C ? Ce qui concerne l'interface l'est certainement, mais le moteur de ces softs, multi-plateforme, est vraisemblablement en C++. Ces boites ne vont pas réécrire des dizaines de millions de lignes de codes en Swift parce qu'il est incompatible avec C++. Je pense qu'elles basculeront peut-être un jour à Swift quand :

    1) Apple leur permettra de faire migrer progressivement leur code (donc en préservant Objective-C)
    2) Apple rendra Swift compatible avec C++.

    En attendant, tant qu'Objective-C++ et sa compatibilité C++ est maintenu, et que je peux continuer à donner mon avis, ça me convient... B)

    le souci avec ton raisonnement c'est qu'Apple va prévenir des années avant les grosses boites en leur disant
    attention Objective-c c'est le fini en 20XX, alors que toi tu vas le savoir uniquement a une WWDC quelques mois avant ! ca craint alors pour tes softs pour faire une transition dans de bonne condition

    C'est pas faut !

  • CéroceCéroce Membre, Modérateur

    @klog a dit :
    Bien entendu, contrairement à toi, j'en sais absolument rien... :/

    Pour être clair, je n'en sais pas grand chose non plus, n'étant pas un spécialiste ni des langages ni des compilateurs. Seul quelqu'un qui travaille sur LLVM tous les jours pourrait nous renseigner.

    Je ne cherche pas à dénigrer les compétences de personne, mais sérieux, ton message a des accents trollesques. Tu demandes ce qui empêche d'assurer une compatibilité, je donnais l'exemple de l'allocation mémoire. Toi même en y réfléchissant, tu parles de l'import des modules C++ et comment traduire les noms des méthodes selon la syntaxe Swift. Et ça, ce sont juste des exemple de ce à quoi nous pensons nous, en tant qu'utilisateurs.

    Nous pouvons être d'accord que si Apple le voulait vraiment, elle travaillerait sur ce sujet, tout comme elle l'a fait pour rendre Swift compatible avec Objective-C. Mais ce n'est certainement pas facile. Non.
    Et ça se ferait au détriment d'autre chose, parce que même Apple, l'une des sociétés les plus riches au monde doit composer avec les limites de ses ressources.

    Rendre compatibles des langages de programmation n'a rien d'extraordinaire, et c'est pratiqué depuis des lustres...

    Le seul dénominateur commun que je connaisse est le C, la lingua franca avec laquelle tous les langages ou presque sont capables de s'interfacer. Quand Python s'interface avec Objective-C, c'est faisable assez facilement parce que le runtime Objective-C est accessible en C.

  • klogklog Membre
    mars 2019 modifié #38

    @Pyroh a dit :

    @devulder a dit :

    @klog a dit :

    @Céroce a dit :

    Franchement, qu'est-ce qui empêche techniquement Apple de faire avec Swift ce qu'elle a fait avec Objective-C, en permettant une certaine interopérabilité de C++ dans du code Swift ? À mon avis rien...

    Et le manque de temps et d'ingénieurs assez qualifiés, ça ne compte pas ?
    Tu n'as aucune idée de la difficulté de la tâche.

    Bien entendu, contrairement à toi, j'en sais absolument rien... :/

    Rien que la gestion mémoire (ou plutôt son absence) en C++ rend l'interopérabilité avec Swift très difficile.

    Ils l'ont bien fait il y a 10 ans avec Objective-C et ARC, totalement compatibles avec C++... Et il n'est même pas nécessaire qu'ils permettent l'inclusion de code C++ directement à l'intérieur de code Swift. Simplement que soit possible l'import de modules C++, l'allocation d'objets C++, et leurs utilisations en Swift, en suivant la syntaxe Swift s'il le faut. Rendre compatibles des langages de programmation n'a rien d'extraordinaire, et c'est pratiqué depuis des lustres...

    Il s'agit vraisemblablement d'une restriction volontaire, dont l'objet est peut-être de maintenir captifs les développeurs iOS.

    Oui, il s'agit d'une restriction volontaire, mais il n'y a pas besoin d'explications complotistes.

    J'ai bien précisé "peut-être"... Loin de moi toute idée "complotistes"... Que tu mésestimes mes compétences, passe encore, mais pour le coup je te trouve un poil agressif... Mon avis vaut le tien, et on peut ne pas être d'accord sans disqualifier ou méjuger son interlocuteur.

    Les ingés d'Apple doivent se fixer des priorités. La stabilité des ABI qui arrive seulement avec Swift 5 aura certainement beaucoup plus d'impact pour la plupart des programmeurs Swift que l'interopérabilité avec C++ (qui n'est pas impossible, mais qui oblige à passer par Objective-C).

    Je radote, mais je t'invite à écrire une passerelle C++/Objective-C/Swift pour une bibliothèque de plusieurs dizaines d'objets... Les développeurs ont autres chose à f...aire que de se coltiner de la glue. Tu crois franchement qu'Office, Photoshop, Autocad, Cinéma 4D, Final Cut, sont totalement écris en Objective-C ? Ce qui concerne l'interface l'est certainement, mais le moteur de ces softs, multi-plateforme, est vraisemblablement en C++. Ces boites ne vont pas réécrire des dizaines de millions de lignes de codes en Swift parce qu'il est incompatible avec C++. Je pense qu'elles basculeront peut-être un jour à Swift quand :

    1) Apple leur permettra de faire migrer progressivement leur code (donc en préservant Objective-C)
    2) Apple rendra Swift compatible avec C++.

    En attendant, tant qu'Objective-C++ et sa compatibilité C++ est maintenu, et que je peux continuer à donner mon avis, ça me convient... B)

    le souci avec ton raisonnement c'est qu'Apple va prévenir des années avant les grosses boites en leur disant
    attention Objective-c c'est le fini en 20XX, alors que toi tu vas le savoir uniquement a une WWDC quelques mois avant ! ca craint alors pour tes softs pour faire une transition dans de bonne condition

    Si Apple doit déprécier Obj-C elle le fera à une WWDC et tout le monde sera au jus en même temps sauf les gros acteurs du marché qui auront été consulté. Mais Apple ne déprécie rien pour le supprimer 2 mois après on est sur des cycles de 2~3 ans voire plus.

    C'est vrai... Mais parfois, même 2 ou 3 ans ça reste short... Il y a un soft, Cheetah 3D, dont le concepteur, qui s'en explique sur le forum officiel du logiciel, doit convertir toute la partie 3D (OpenGL désormais deprecated) en Metal. Et bein j'aimerais pas être à sa place... Pendant qu'il fait ce taf, il fait du sur place coté fonctionnalités. Et convertir d'une API 3D à l'autre, ça reste accessible relativement à l'effort que représenterait la conversion de milliers de lignes de codes en Swift :'(

  • klogklog Membre

    @Céroce a dit :

    @klog a dit :
    Bien entendu, contrairement à toi, j'en sais absolument rien... :/

    Pour être clair, je n'en sais pas grand chose non plus, n'étant pas un spécialiste ni des langages ni des compilateurs. Seul quelqu'un qui travaille sur LLVM tous les jours pourrait nous renseigner.

    Pas seulement... Tous ceux qui ont peu ou prou touché à la théorie des langages ou décortiqué un compilateur peuvent avoir une idée du degré de complexité du machin. Et je maintiens que c'est relativement peu complexe. La plupart des "jeunes" langage intègrent d'ailleurs assez vite une compatibilité avec l'extérieur, garantie importante d'une sortie de l'anonymat.

    Je ne cherche pas à dénigrer les compétences de personne, mais sérieux, ton message a des accents trollesques.

    Au contraire ! Je regrette de ne pouvoir basculer sur Swift en raison d'une absence majeure... Il n'y a pas plus belle déclaration d'amour ! :)

    Tu demandes ce qui empêche d'assurer une compatibilité, je donnais l'exemple de l'allocation mémoire. Toi même en y réfléchissant, tu parles de l'import des modules C++ et comment traduire les noms des méthodes selon la syntaxe Swift. Et ça, ce sont juste des exemple de ce à quoi nous pensons nous, en tant qu'utilisateurs.

    Nous pouvons être d'accord que si Apple le voulait vraiment, elle travaillerait sur ce sujet, tout comme elle l'a fait pour rendre Swift compatible avec Objective-C. Mais ce n'est certainement pas facile. Non.
    Et ça se ferait au détriment d'autre chose, parce que même Apple, l'une des sociétés les plus riches au monde doit composer avec les limites de ses ressources.

    Rendre compatibles des langages de programmation n'a rien d'extraordinaire, et c'est pratiqué depuis des lustres...

    Le seul dénominateur commun que je connaisse est le C, la lingua franca avec laquelle tous les langages ou presque sont capables de s'interfacer. Quand Python s'interface avec Objective-C, c'est faisable assez facilement parce que le runtime Objective-C est accessible en C.

    La seule chose que j'essaye (visiblement maladroitement) de dire, c'est que Swift ne pourrait devenir le langage de facto d'Apple, que s'il assurerait à minima un certain de degré de compatibilité avec les choses déjà écrites. Au risque de fermer la porte aux développeurs déjà passablement éreintés par les multiples conversions qui émaillent l'histoire de macOS (Carbon -> Cocoa, Motorola -> Intel, 32 -> 64, OpenGL / OpenCL -> Metal, ...)

  • Mouaip, vu qu'apple est synonyme de pognon pas certain que les dev lachent comme ça.

    La première diff se voit sur les stores, dès qu'une application est payante chez google t'as le droit à tous les enragés qui vont coller une sale note parce que le logiciel est payant alors que dans le monde apple il est normal de payer pour un travail.

    Sur android et pour en avoir fait les frais, même si ton application est 100% libre avec source dispo t'aura toujours ces enragés pour te coller une sale note temps que tu ne te sera pas plié à leur volonté...
    "- je mettrai 5 étoiles quand l'application intégrera la fonctionnalité X"
    "- je retire des étoiles parce que le dev ne répond pas à ma demande"

    Un peu comme les hôtels qui sont prit en otage par des raclures qui font du chantage à la sale note sur internet si tu refuses de réduire sa note voir la gratuité totale.

    J'ai pas vraiment vu ça du coté d'apple, les gens y sont plus individualiste mais plus éduqué aussi.

    A toi de choisir si tu préfères travailler au Carlton ou dans un formule 1 qui sent des pieds :)

    Chez microsoft j'en sais rien mais c'est aussi un OS principalement utilisé par des gueux :p

    Après pour C++ et Objective-C qui vont disparaître j'ai de gros doute que ça disparaisse comme ça, à un moment ou à un autre il faut redescendre de niveau si tu veux plus de contrôle sur tes applications sans forcément avoir besoin de taper dans le C ou l'ASM. Faudrait pas confondre fantasme et réalité.

  • MalaMala Membre, Modérateur

    @klog a dit :
    La seule chose que j'essaye (visiblement maladroitement) de dire, c'est que Swift ne pourrait devenir le langage de facto d'Apple, que s'il assurerait à minima un certain de degré de compatibilité avec les choses déjà écrites. Au risque de fermer la porte aux développeurs déjà passablement éreintés par les multiples conversions qui émaillent l'histoire de macOS (Carbon -> Cocoa, Motorola -> Intel, 32 -> 64, OpenGL / OpenCL -> Metal, ...)

    Je te rejoins complètement.

  • klogklog Membre

    @Harlo a dit :
    Mouaip, vu qu'apple est synonyme de pognon pas certain que les dev lachent comme ça.

    Le marché pro macOS se réduit en tout cas de jour en jour... Les secteurs autrefois porteurs ne le sont plus (vidéos, presse & PAO, 3D, architecture, ...)

    Après pour C++ et Objective-C qui vont disparaître j'ai de gros doute que ça disparaisse comme ça, à un moment ou à un autre il faut redescendre de niveau si tu veux plus de contrôle sur tes applications sans forcément avoir besoin de taper dans le C ou l'ASM. Faudrait pas confondre fantasme et réalité.

    Entièrement d'accord !

  • @klog a dit :
    Le marché pro macOS se réduit en tout cas de jour en jour... Les secteurs autrefois porteurs ne le sont plus (vidéos, presse & PAO, 3D, architecture, ...)

    J'en viens à me demander ce qu'est le marché pro maintenant sur macOS, voire même le marché tout court.
    Je suis activement en train de développer des outils et applications mac dans le but de me lancer en parallèle de mon travail et j'avoue ne pas savoir exactement à quoi je dois m'attendre en terme de clientèle.

  • klogklog Membre
    mars 2019 modifié #44

    @Pyroh a dit :

    @klog a dit :
    Le marché pro macOS se réduit en tout cas de jour en jour... Les secteurs autrefois porteurs ne le sont plus (vidéos, presse & PAO, 3D, architecture, ...)

    J'en viens à me demander ce qu'est le marché pro maintenant sur macOS, voire même le marché tout court.
    Je suis activement en train de développer des outils et applications mac dans le but de me lancer en parallèle de mon travail et j'avoue ne pas savoir exactement à quoi je dois m'attendre en terme de clientèle.

    A un marché de niche, avec ses inconvénients (restreint) et ses avantages (peu de concurrent et un marché à portée d'indépendants)... Après tout dépend du secteur et de la cible... Mais dans l'ensemble, difficile par exemple de faire du logiciel de petite audience sur un marché de niche, à moins d'en multiplier le nombre. Et concernant les pros, une grosse charrette de ceux qui ont pris le wagon du Mac à la belle époque sont en train de partir à la retraite.

  • Dans les boîtes ou je suis passé c'était principalement vidéo, PAO, photo mais ils ont tous basculé sous windows et ça a commencé quand apple à viré intel et que les prix ont grimpé.
    Pour beaucoup c'était la même réflexion: pourquoi payer ce prix là pour du PC qui coute 2x moins cher et capable de faire la même chose.
    Le plus flagrant que j'ai vu c'était un p'tit journal local, 150 machines environ, migrer en windows.
    Ce qui a fait le plus mal a été de voir des serveurs SUN se faire remplacer par du dell sous windows pour y coller PHP MySQL et Apache, ça pique les yeux >_< J'avais essayé de leur faire comprendre que quitte à passer sur AMP autant le faire sous linux qui reste un *nix était le plus logique et qu'ils s'épargneraient le prix de licence windows serveur n'y a rien fait. P'têt qu'il y a eu quelqu'un qui s'est fait acheter par un commercial de chez M$ ?

    Une autre chose que je comprend mal c'est qu'apple n'a plus l'air de compliquer la vie à ceux qui tentent d'installer MacOS sur du PC. La première fois que j'avais fait ça il fallait bricoler le noyau et apple rajoutait des sécurités de façon aléatoire dans une partie de l'interface graphique. A chaque mise à jour il me fallait bien entre 1 journée et une semaine pour réussir à l'installer. Il fallait aussi changer la signature des pilotes et s'arranger pour prendre des composant identique aux config des Mac. Maintenant t'arrive à l'installer sur n'importe quoi.

    Sur un fofo dédié hackintosh grand publique j'ai vu des "génies" décidé de créer une pétition à envoyer à apple pour que les cartes graphique nvidia soient mieux supporté (des modèles qui n'ont jamais été intégré dans des mac bien entendu). Je trouve bizarre qu'apple ne réponde pas plus durement et je doute que la pomme ignore ça.

    Un autre questionnement, c'est la monté subite du prix des machines. Quand je vois qu'un mac mini peut facilement dépasser les 3500€ et un iMac les 15000€, 100€ pour une malheureuse souris (pas très précise en plus) et 150€ pour un bête clavier même pas mécanique.

    J'en suis à me demander si:

    1) une partie des actionnaires chercher à s'en coller plein les poches avant de partir
    2) apple n'aurait pas besoin de fonds important pour partir dans une toute autre direction
    3) est-ce que MacOS ne serait pas revendu à un moment ou à un autre
    4) est-ce que apple va rester une boîte grand publique ou tenter de se la jouer IBM

  • @Pyroh a dit :

    Je suis activement en train de développer des outils et applications mac dans le but de me lancer en parallèle de mon travail et j'avoue ne pas savoir exactement à quoi je dois m'attendre en terme de clientèle.

    Dans l'état actuel des choses c'est extrêmement risqué.

  • muqaddarmuqaddar Administrateur

    @Draken a dit :

    @Pyroh a dit :

    Je suis activement en train de développer des outils et applications mac dans le but de me lancer en parallèle de mon travail et j'avoue ne pas savoir exactement à quoi je dois m'attendre en terme de clientèle.

    Dans l'état actuel des choses c'est extrêmement risqué.

    Je suis d'accord. Mais la passion...

    Il y a plein d'inconnues sur Mac:

    • la taille du marché suivant la cible (et le prix des machines est sûrement en grande partie responsable de la taille du marché)
    • l'AppStore et ses différents modèles (vente, abonnement...)
    • l'AppStore et son futur (j'ai peur des abonnements à 9,90 pour toutes les apps dans le futur ?)

    Augmenter les prix des Mac est dangereux dans le sens où il ne faut pas flinguer la taille du marché pour les devs. A partir d'un certain pourcentage tout peut s'écrouler. C'est ce qui s'est passé pour les Mac dans les années 90.
    Si Apple reproduit cette erreur sur iOS, attention.

  • @Draken a dit :

    @Pyroh a dit :

    Je suis activement en train de développer des outils et applications mac dans le but de me lancer en parallèle de mon travail et j'avoue ne pas savoir exactement à quoi je dois m'attendre en terme de clientèle.

    Dans l'état actuel des choses c'est extrêmement risqué.

    Là dessus on est entièrement d'accord c'est pour ça que je conserve mon emploi actuel. Je fais juste ça en plus, à mon rythme sans trop en attendre si ce n'est un peu d'argent de poche (j'ai déjà un outil gratuit dispo sur mon site.
    Tout ça est teinté du rêve d'en vivre un jour bien entendu mais je me vois plus comme un quelqu'un qui est peintre ou coutelier sur son temps libre et qui vend de temps en temps un truc. C'est plus pour le plaisir qu'autre chose.

    Après j'avoue que je comprends le principe de l'abonnement si ça reste correct, à savoir un prix mensuel honnête et une vraie valeur ajoutée en échange de mes sous. Je paie à l'année pour deux soft : (Sketch)[https://www.sketch.com] et Tower parce que je les utilise tous les jours aussi bien personnellement que professionnellement. Je ne vois une valeur ajoutée que pour Sketch, Tower est passé il y a moins d'un an en mode abonnement et je ne sais pas si je vais renouveler pour un an tant l'app commence à stagner.

    C'est là le soucis je pense, il y a de potentiels utilisateurs prêts à payer pour des apps mais il faut leur en donner pour leur argent et sur le long terme. C'est un pari et à ce sujet je pense que le créateur Kite est en train de le perdre.

    Au pire il nous restera toujours l'open-source pour nous exprimer 😉

  • C'est une tuerie ce Kite O_o

  • CéroceCéroce Membre, Modérateur

    @klog a dit :
    La seule chose que j'essaye (visiblement maladroitement) de dire, c'est que Swift ne pourrait devenir le langage de facto d'Apple, que s'il assurerait à minima un certain de degré de compatibilité avec les choses déjà écrites. Au risque de fermer la porte aux développeurs déjà passablement éreintés par les multiples conversions qui émaillent l'histoire de macOS (Carbon -> Cocoa, Motorola -> Intel, 32 -> 64, OpenGL / OpenCL -> Metal, ...)

    Moi aussi, je vais me lancer à essayer maladroitement d'expliquer mon sentiment. Mais pour résumer, Objective-C regarde vers le passé alors que Swift regarde vers l'avenir.

    Attention, on a besoin du passé! Parce qu'il existe de grosses bases de code existant, et que les convertir n'est pas économiquement viable, ou ne branche personne.

    Remarquons qu'Apple en interne utilise C++ dans de nombreux projets. De ceux que je connais, il y a au moins Scene Kit, Core Audio, WebKit. Donc, cette passerelle qui oblige à avoir une couche ObjC entre C++ et Swift fait quand même son boulot. Nous sommes d'accord que ce n'est pas idéal, que ça a un impact sur les performances, et que le boulot peut devenir titanesque, au point où à mon avis, certains s'en sortent avec de la génération de code.
    D'ailleurs Apple traine la patte pour convertir ses propres applications en Swift.

    Cependant, le gros de la programmation d'aujourd'hui, ce n'est plus réécrire le pilote de la carte graphique pour gagner quelques cycles. D'ailleurs Objective-C n'a jamais été un langage de bas niveau non plus. C'est pour cela que je ne pense absolument pas que la compatibilité avec C++ soit cruciale pour le succès de Swift à court, moyen ni long terme.

    Son succès dépendra en partie de sa capacité à relever les défis d'aujourd'hui et de demain. La modernité qu'il apporte (syntaxe des closures, types immutables, génériques, programmation fonctionnelle) est déjà la bienvenue pour gérer une complexité fonctionnelle toujours plus importante et l'asynchronisme. Cependant, Kotlin étant très similaire, ses seules qualités ne suffiront pas.

    Il y a des efforts pour le faire sortir du carcan Mac/iOS: Swift sur le serveur ou par exemple Swift pour TensorFlow. Il y a aussi le potentiel, grâce à llvm, de pouvoir générer du WebAsm.

  • Mouaip, les langages "d'avenir" j'y crois pas trop.

    Plus il y a diversification et plus les dev choisissent ce qui leur convient le mieux dans la souplesse et la syntaxe.
    La seule chose qui oblige à pencher sur un langage plus qu'un autre c'est le système sur lequel il tourne et encore... il y a toujours moyen de contourner ça d'une façon ou d'une autre.

    Le CPU il s'en moque totalement de savoir si ses instructions ont été écrite en C, Java ou swift. Le seul moyen de tuer un langage c'est de tuer son compilateur et c'est pas prêt d'arriver.

    Swift n'est pas un langage d'avenir, c'est un langage actuel qui tente d'avoir un avenir et c'est le prosélytisme de ses adeptes qui fera la différence. Apple sait exploiter le fanatisme mais sa politique commercial joue contre lui donc à voir.

  • @Harlo a dit :

    Swift n'est pas un langage d'avenir, c'est un langage actuel qui tente d'avoir un avenir et c'est le prosélytisme de ses adeptes qui fera la différence. Apple sait exploiter le fanatisme mais sa politique commercial joue contre lui donc à voir.

  • LeChatNoirLeChatNoir Membre, Modérateur

    De mon côté, la réflexion autour de l'abonnement est en train de virer au rejet...
    Je crois que ce mode de fonctionnement est très Américain et je commence à penser que je n'irai pas dans cette direction.
    Parce qu'entre nous, cette histoire d'abonement, ça arrange qui ?
    Uniquement Apple et Google qui pensent transformer des achats ponctuels en revenus réccurents. Et ils poussent les dev à y aller avec leur taxe qui baisse "dès" la 2eme année.

    Je suis pas fan. Un peu marre de ces boites qui poussent à la conso... L'achat unique me paraît plus "made in France". Ca peut paraitre con mais je commence à le croire.

  • @LeChatNoir a dit :

    Parce qu'entre nous, cette histoire d'abonement, ça arrange qui ?

    C'est très bien l'abonnement, du moins pour certaines choses. Le problème c'est le montant délirant. On dirais que dans la tête des éditeurs, c'est minimum 10 €/mois ..

  • muqaddarmuqaddar Administrateur
    mars 2019 modifié #55

    @LeChatNoir a dit :
    De mon côté, la réflexion autour de l'abonnement est en train de virer au rejet...
    Je crois que ce mode de fonctionnement est très Américain et je commence à penser que je n'irai pas dans cette direction.
    Parce qu'entre nous, cette histoire d'abonement, ça arrange qui ?
    Uniquement Apple et Google qui pensent transformer des achats ponctuels en revenus réccurents. Et ils poussent les dev à y aller avec leur taxe qui baisse "dès" la 2eme année.

    Je suis pas fan. Un peu marre de ces boites qui poussent à la conso... L'achat unique me paraît plus "made in France". Ca peut paraitre con mais je commence à le croire.

    C'est compliqué.
    Le problème on le connaît. Moi, j'en suis à ma cinquantième MAJ "gratuite" de mon app depuis 2012.
    Cela ne pourra plus continuer.
    D'autant plus que j'ai 200 euros de frais de serveurs OVH+AWS par mois.

    @Draken a dit :

    @LeChatNoir a dit :

    Parce qu'entre nous, cette histoire d'abonement, ça arrange qui ?

    C'est très bien l'abonnement, du moins pour certaines choses. Le problème c'est le montant délirant. On dirais que dans la tête des éditeurs, c'est minimum 10 €/mois ..

    Moi je viserais plutôt 10 euros/an, c'est déjà mieux que 10 euros à vie...

    Mais c'est toujours pareil: ceux qui l'utilisent tous les jours et ceux qui l'utilisent 3 fois par an paient la même chose. Mais c'est pareil pour un achat.

    Ma question, c'est plutôt de savoir si il vaut mieux:

    • 5000 clients à 10 euros
    • 2000 clients à 50 euros
    • ...

    Bref, c'est impossible de savoir combien sont prêts à payer combien, même avec un sondage où seuls les intéressés répondront... qu'ils préfèrent payer moins évidemment.

  • @muqaddar a dit :

    Moi je viserais plutôt 10 euros/an, c'est déjà mieux que 10 euros à vie...

    Absolument. C'est ce que j'ai toujours pensé.

  • @muqaddar a dit :
    Ma question, c'est plutôt de savoir si il vaut mieux:

    • 5000 clients à 10 euros
    • 2000 clients à 50 euros

    vaut mieux 2000 clients à 50€, ça fait moins d'emmerdeurs, t'évite les n00b qui vont sortir que ton appli a cassé leur matériel parce qu'il est tombé en panne pile après l'avoir installé, moins de questions stupide, moins de temps à faire du support etc.

    Le rapport direct à l'utilisateur c'est une plaie et je parle en connaissance de cause, ça m'a fait lâcher l'informatique à titre pro.

  • klogklog Membre
    mars 2019 modifié #58

    @Harlo a dit :

    @muqaddar a dit :
    Ma question, c'est plutôt de savoir si il vaut mieux:

    • 5000 clients à 10 euros
    • 2000 clients à 50 euros

    vaut mieux 2000 clients à 50€, ça fait moins d'emmerdeurs, t'évite les n00b qui vont sortir que ton appli a cassé leur matériel parce qu'il est tombé en panne pile après l'avoir installé, moins de questions stupide, moins de temps à faire du support etc.

    Le rapport direct à l'utilisateur c'est une plaie et je parle en connaissance de cause, ça m'a fait lâcher l'informatique à titre pro.

    Tu dis vrai !

    • Alors commencez par aller dans le Finder p...
    • C'est quoi le Finder ?

    Et c'est du vécu récurrent, hein... Pas un cas sur 100... Et je parle de gars qui sont sur Mac depuis des plombes !

  • muqaddarmuqaddar Administrateur

    @Harlo a dit :

    @muqaddar a dit :
    Ma question, c'est plutôt de savoir si il vaut mieux:

    • 5000 clients à 10 euros
    • 2000 clients à 50 euros

    vaut mieux 2000 clients à 50€, ça fait moins d'emmerdeurs, t'évite les n00b qui vont sortir que ton appli a cassé leur matériel parce qu'il est tombé en panne pile après l'avoir installé, moins de questions stupide, moins de temps à faire du support etc.

    Le rapport direct à l'utilisateur c'est une plaie et je parle en connaissance de cause, ça m'a fait lâcher l'informatique à titre pro.

    Oui, je sais ça, et je suis d'accord.
    Moins on en a, mieux on se porte. ;-)

    Mais si tu te retrouves avec 2000 clients à 10 euros, là tu foires ton coup.

  • Ben, t'as que l'étude de marché ou tenter par la chance.

    Pour l'étude de marché soit tu fais un synthèse à partir d'un produit déjà existant qui correspond à ton application en prenant en compte toutes les critiques qui sont faite en y répondant (si elle ne sont pas trop minoritaire).
    Si c'est un truc innovant tu prend le risque de la dévoiler en questionnant des personnes via une entreprise ou des sites qui accepteront de coopérer avec toi mais c'est prendre le risque que quelqu'un te coupe l'herbe sous le pied.

    Tout dépend aussi de tes moyens, du niveau de com que tu peux te permettre (un pote youtubeur ça peut être pratique). Même la pire des daubes peut être un succès économique avec une com bien comme il faut alors si en plus c'est un truc vraiment utile.

  • @Pyroh a dit :

    @Harlo a dit :

    Swift n'est pas un langage d'avenir, c'est un langage actuel qui tente d'avoir un avenir et c'est le prosélytisme de ses adeptes qui fera la différence. Apple sait exploiter le fanatisme mais sa politique commercial joue contre lui donc à voir.

    Ça manque d'un chat portant aussi un chapeau ..

Connectez-vous ou Inscrivez-vous pour répondre.