Rigolo!
Monsieur Jobs a juré de ne jamais faire de souris à plus d'un bouton, et il tient parole, tout en nous créant Mighty Mouse, une souris qui semble assez intelligente, à plusieurs boutons tout en n'en ayant en apparence toujours qu'un seul, voire aucun.
Tout change. Et c'est tant mieux.
Dites, notre grand chef suprême en quelques mois revient sur pas mal de ses certitudes vous ne trouvez pas?
Et j'aime bien ça.
Mais là n'est pas le sujet, de l'humeur d'aujourd'hui.
Quoique...
J'ai lu sur Mac Génération que CodeWarrior décidait de jeter l'éponge, et ne fera plus évoluer son environnement de développement pour la plateforme Mac-Intel.
Ce n'est pas vraiment une surprise: l'autre jour, j'ai discuté avec un développeur important (dont je tairai le nom pour ne pas le mettre dans cette histoire contre son gré), qui me disait que sa société ne pourrait plus compiler leur application sur Mac-Intel avec CodeWarrior, et qu'un travail énorme pour passer leur logiciel sur la nouvelle plateforme serait nécessaire.
Je lisais aussi les commentaires à cette nouvelle, toujours sur MacGé. Un certain nombre de lecteurs sont ravis de cette annonce.
"Photoshop sera réécrit, modernisé, plus près de notre OS".
"XCode est gratuit, les développeurs ont de la chance".
On parle aussi beaucoup des qualités de XCode, qui semble être en effet excellent, mais là n'est pas vraiment le problème.
Mes amis, j'ai été aussi, à mon petit niveau, confronté à l'abandon d'un système de développement. Il s'agit d'HyperCard, qui n'a pas été porté pour MacOSX.
Et bien je peux vous dire que c'est terrible. Votre travail de plusieurs années, représentant des milliers d'heures de programmation (mais oui), vous pouvez quasiment le mettre à la poubelle. Vous avez deux solutions:
- vous reprenez les idées, mais vous récrivez pratiquement tout
- vous regardez vos logiciels mourir gentiment, puisque de moins en moins de gens sont prêts à lancer Classic, et que même en le faisant, les incompatibilités apparaissent et que de toute façon, Classic ne tournera pas sur la nouvelle plateforme Mac.
Toujours à mon petit niveau, je constate qu'il m'a fallu sept ans, avec un détour par SuperCard, pour mettre à jour mes programmes sur Revolution, et que j'y arrive maintenant seulement, sachant que j'ai abandonné un logiciel (il n'en vaut pas la peine je crois) au passage. C'est d'ailleurs ce qui m'a permis de voir que Cuk Grammaire, l'ancien, ne fonctionne plus convenablement sur Tiger via Classic. Si je ne l'avais pas réécrit, il serait désormais inutilisable (ne téléchargez pas la version actuellement en ligne, la nouvelle n'est pas encore disponible).
D'accord. Comme il faut tout réécrire (avec Revolution, on peut garder une partie du code d'HyperCard, mais comme avec Hypercard j'utilisais des extensions, tout est à revoir), et l'on en profite pour insérer de toutes nouvelles fonctions, pour rendre le programme plus agréable, plus facile d'utilisation.
Mais cela prend tellement de temps...
On me rétorquera que je n'ai pas développé les programmes Cuk à plein-temps. C'est vrai, mais de très nombreux développeurs, la plupart en fait, travaillent aussi à côté (ben oui, faut pas être cher, faut même être gratuit, ça ne nourrit pas tellement une famille, le développement) et n'auront peut-être pas le courage de se remettre au travail en profondeur.
Le passage sur Intel en fait, je m'en fiche un peu. À la limite, je m'en réjouis. Mais ce problème de portage des logiciels, que j'avais évoqué ici au lendemain de l'annonce de Jobs, c'est la seule chose qui me fasse vraiment peur.
J'ai entendu des arguments du type "Bien fait pour les développeurs qui sont restés sur CodeWarrior, ils n'avaient qu'à se mettre sur XCode dès le passage à MacOSX".
Non mais je rêve ou quoi? On va commencer par engueuler les gens qui font confiance au Mac depuis des années? À leur reprocher de ne pas avoir utilisé les outils offerts par Apple?
Le développeur dont je parlais plus haut me disait que pour lui, c'était l'horreur. Le passage au PowerPC, puis à MacOS X leur avait pris énormément de temps de développement, temps qu'ils ne mettaient pas sur l'amélioration proprement dite des performances de leur logiciel.
Alors pour eux, ce passage à Mac-Intel, c'est tout simplement l'horreur, mais son entreprise le fera.
Combien d'autres, suite à cette annonce de CodeWarrior, vont tout simplement eux, lâcher leur logiciel?
Non, décidément l'annonce de l'abandon cet environnement de développement n'est pas une bonne nouvelle, que vous aimiez CodeWarrior ou pas ou que Xcode soit supérieur ou qu'il ne le soit pas.
, le 03.08.2005 à 00:21
La nouvelle est triste en effet, mais le programme utilisé par les développeurs pro a beaucoup moins d’importance que dans le cas des développeurs « amateurs » (Hypercard, RealBasic, Révolution,…).
Dans le cas des programmes « amateurs », il y a en gros un fichier projet au format propriétaire qui inclus tout, y compris le code source (je n’ai pas connu hypercard), donc effectivement passer d’un IDE à un autre implique la réécriture du code. Sans compter les différences de langage entre les différents IDE.
Maintenant si on regarde les programmes pro, le code est dans des fichiers séparés du fichier projet lui même, ce sont de simples fichiers texte. Le fichier projet quant à lui contient surtout la liste des fichiers à inclure dans le projet, la composition des sous-projets, les paramètres de compilation… Passer à un autre IDE est donc gênant, car il faut apprendre un nouveau logiciel, et il faut refaire le fichier projet (ce qui représente beaucoup de boulot dans le cas des gros projets). Mais le code source reste inchangé et peut être réutilisé tel quel (si on a pas à gérer le problème du changement de processeur bien sur).
Sinon la raison dont ne parle pas Metrowerks pour l’abandon de CodeWarrior, c’est justement la percée d’Xcode. Les chiffres donnés par Apple lors de la WWDC situaient la part de marché de Xcode à près de 80% si mes souvenirs sont bons (en incluant ceux qui étaient en cours de migration).
, le 03.08.2005 à 00:24
C’est malheureusement le lot quotidien du programmeur/développeur que de constamment apprendre des api, des librairies, des nouveaux languages…
Un programme qui n’évolue pas, qui n’est pas recompilé pour les nouveaux os… meurt tout simplement!
Personnellement, j’ai développé pas mal d’appli et à chaque fois, il faut presque apprendre un nouveau langage.
Le pire, c’est les applis que l’on développe pour soit et dont on a besoin. Exemple : ma base Filemaker pour gérer mes comptes. Ouf, filemaker 5.5 fonctionne toujours mais avec Mac-Intel, je sais pas trop…
Dernièrement, j’ai mis la main à la pate sur un logiciel pour Mac à vocation d’être diffusé. J’ai hésité sur le langage… Java était tentant mais il y avait un risque de mise à l’écart par Apple.
Finalement, j’ai opté pour XCode et Objective-C (à cette époque je n’étais pas au courant du virage Intel). Et bien, j’avoue que j’ai bien fait d’apprendre l’Objective-C parce que je ne sais pas si j’aurai continué mon dév avec le risque d’une impasse. Là avec XCode, je suis à peu près serein sur le double binary…
Mais de toute façon, je ne me fais pas d’illusion si XCode est abandonné ou changé au profit de XXX ou si l’objective-C n’est plus supporté au profit du C++… cela impliquera une refonte terrible à supporter quand on développe en individuel sans gagner un centime avec!
Bref, les langages et les technologies informatique, qui apparaissent et disparaissent, contribuent finalement au cycle de vie logiciel. Cela tue les logiciels et seules les espéces adaptées au nouvel environnement survive. Ceux qui meurt laisse ainsi la place à de nouvelles tentatives plus fructueuse.
En quelque sorte, Darwin appliqué aux logiciels… pour le pire et le meilleur ;)
, le 03.08.2005 à 00:50
Moi je ne comprends pas pourquoi on en fait tout un foin. En fait je croyais que CodeWarrior était déjà abandonné depuis un petit moment. En tout cas les versions permettant de compiler autre chose que pour mac (palm par exemple) ont progressivement disparu de la version mac de codewarrior, la dernière fois que j’ai regardé (il y a longtemps).
Bref, pour moi c’est un non-évènement, dans la mesure où c’était très prévisible, attendu, et même avant l’annonce des mac intel. Ça n’en est pas moins un coup dur pour les développeurs qui l’utilisent, et la piètre qualité de XCode dans bien des domaines n’est pas pour les aider…
, le 03.08.2005 à 01:08
Le développement, activité professionnelle ou activité amateur, est et restera très directement liée aux évolutions technologiques.
J’ai débuté il y a de nombreuses années, et j’ai déjà vécu des tas de changements d’environnement (IDE, language, plateforme). Ainsi qu’une portion non négligeable des développeurs actifs depuis longtemps, à n’en pas douter.
Pour ce qui touche au Mac, j’ai utilisé Pascal sous MPW. Abandonné. Puis C sous MPW. Abandonné. Puis ThinkPascal. Abandonné. Puis Symantec C++. Abandonné. Puis CodeWarrior C++. Maintenant abandonné. Un peu d’Hypercard au passage. Abandonné.
Hors Mac, j’ai bossé sur plusieurs plateformes, desktop ou embarqué. La plupart abandonnées. La dernière en date, OS/2. La précédente ou presque, Tru64.
Metrowerks, racheté par Motorola, a vendu ses technologies Intel. A l’annonce du passage sur Intel, c’était évident que l’avenir de CodeWarrior était plus que sombre. L’abandon de CodeWarrior n’est pas une nouvelle, sauf éventuellement pour un développeur rentrant de Koh Lanta.
Côté Windows, les choses ne sont pas roses non plus. Ceux qui n’ont pas opté depuis le départ pour Visual Studio ont souvent souffert. Les évolutions de Visual Studio n’ont pas été des plus simples qui plus est. Avec .NET, ça s’est encore compliqué d’un cran.
Bref, c’est la vie. Chaque changement de version de compilateur occasionne des souffrances. La recompilation des drivers pour un certain fabriquant de souris en Universal Binary a été difficile non pas à cause de l’architecture Intel, mais à cause des changements entre gcc 3 et gcc 4. Pour les drivers MacOS 8/9 du même fabriquant, j’ai été régulièrement emmerdé par les changements entre CodeWarrior n et n+1, avec les évolutions des PowerPlant… ces mêmes drivers ont d’ailleurs été réécrits complètement (mais alors vraiment complètement) lors du passage de MPW vers CodeWarrior, trop fastidieux à adapter. Et lorsque j’ai switché de CodeWarrior à Xcode (1.0 !), j’ai pas trop apprécié la transition.
Le pire, c’est l’Open Source. La plupart du temps, si on veut profiter des bug fixes, il faut prendre la dernière version. Les anciennes versions ne sont pas patchées. Et lorsque les modules open source se multiplient dans un projet (je fais pas mal de Java), ça devient une galère épouvantable à gérer.
La morale de l’histoire est que plus on est proche de l’informatique, et le développeur en est vraiment très très proche, plus l’informatique (et cette saleté d’ « obsolescence programmée ») devient emmerdante.
L’informatique est une mauvaise nouvelle. L’informatique m’emmerde tous les jours, même pendant mes vacances.
Je suis un grand masochiste, j’adore ça.
, le 03.08.2005 à 07:38
François, avec des arguments comme celui-ci, on en serait encore à la lampe à huile… Chaque évolution laisse des gens sur le carreau qui ont posé leurs valises en pensant qu’ils étaient arrivés… Malheureusement, ce n’est pas le cas, on ne s’arrête jamais et cela va d’ailleurs finir dans un grand feu d’artifice général… Mais ceci est une autre histoire.
Macdigit
, le 03.08.2005 à 07:39
NB : d’autant que d’autres développeurs (que tu connais aussi) pensent que cela va leur prendre une petite journée… Bref, c’est le problème de faire le bon choix au bon moment…
Macdigit
, le 03.08.2005 à 07:59
Laisser des gens sur le carreau, cela veut dire par exemple des professionnels (non informaticiens) bloqués sur MacOS 9, sans alternative et avec l’impossibilité de récupérer leurs données.
Je ne comprends pas la réflexion de Guillôme (je précise
que je suis pas informaticien) concernant FileMaker Pro. C’est une filliale d’Apple, donc il ne devrait pas y à avoir de souci, non? (peut-être au prix d’une màj au prix
exhorbitant, comme d’habitude).
Divoli
, le 03.08.2005 à 08:15
Jean-Christophe, oui, certains développeurs n’ont qu’une case à cocher pour que leur logiciel passent sur MacIntel.
D’autres non. Et ce n’est pas parce qu’ils ont fait le mauvais choix. CW en était un excellent.
Le problème de ces développeurs, c’est qu’ils passent leur temps à devoir s’adapter aux nombreux changements de caps qu’Apple leur impose.
Je dis juste que l’abandon de CodeWarrior n’est pas une bonne chose, et que tout ne sera pas aussi rose que ce que Monsieur Jobs a bien voulu nous dire.
, le 03.08.2005 à 08:49
Pour FileMaker Pro, il ne devrait pas y avoir de problème puisqu’il est déjà en version Mac et Window depuis la version 3 (ou même 2.1).
, le 03.08.2005 à 09:07
Concernant FileMaker, il est vrai qu’il ne devrait pas y avoir trop de problème et je n’en ai jamais eu mais, pour tempérer cela :
– Ma base utilise le langage de script de Filemaker 5.5, rien ne dit que les actions programmées, les requêtes, les rapports… seront 100% compatibles avec une nouvelle version Mac Intel! Dans un autre registre, j’avais fait la douloureuse expérience de convertir une base Access 98 en Access 2000. Et comme par hasard, plein de trucs étaient à refaire!
– Rien ne prouve qu’un jour Apple ne va pas abandonner FileMaker! Et là, obligation de passer à 4D ou au remplaçant apple de Filemaker…
Sinon, mon commentaire rejoint celui de jean-christophe courte, l’évolution est épuisante mais c’est un mal nécessaire!
, le 03.08.2005 à 09:13
Je suis du même avis que arldon, un programme bien foutu ne nécessitera qu’une petit adaptation à XCode. A priori, on parle juste du code « main », le reste ne changera pas.
Plus mauvaise nouvelle par contre, c’est l’incertitude face à l’utilisation de Cocoa-Java sous MacTel. Je m’attends à devoir reprogrammer tous mes logiciels en Obj-C… mais c’est pas dramatique, là encore, une bonne partie de mon code sera réutilisable.
Et François, tu dis:
Jobs à bien dit à la WWDC que les gens travaillant sous CW devront passer sous XCode. Il l’a dit en souriant, certes, mais il à tout de même mentionné le problème.
Quant à CW, le problème n’est à mon avis pas tant de faire un compilateur pour Intel que de faire un compilateur en Universal Binaries.
, le 03.08.2005 à 09:40
Bonjour,
Je penses qu’il est plutot difficile de choisir la plate-forme de developement qui permet d’etre a la fois efficace et de garantir une certaine pérennité.
De plus en l’informatique personnelle évolue rapidement. Pour ma part j’ai choisi récement le langage Java pour sa richesse mais surtout parce je penses que java sera toujours là dans 10 ans. En effet de nombreuses entreprises utilisent la plate-forme java pour des applications métiers qui coutent cher a developper, a tester et ou les erreurs coutent cher. Les langages COBOL, FORTRAN ou ADA sont toujours utilises et surtout supportes de par ce fait.
Je ne connais pas assez l’environnement macintosh pour savoir s’il existe quelque chose de similaire mais je n’en suis pas sur.
Pour l’annecdote pour mon premier travail en tant que salarié, j’ai ete affecte a un projet qui s’occupait de la facturation de services pour une grosses entreprises. Ce projet consistait a tracer les services prestés et a envoyer les informations vers les programmes comptables.
Au depart le client souhaitais de travailler avec toute une serie de technologie qui etais a la mode dans les journeaux specialises (Windows NT, VB, COM+, SQL server,…). La société de service n’y voyait pas de soucis jusqu’a ce qu’on arrive a la question des astreintes de 500k€ par quart d’heure d’indisponibilite d’un des serveurs (il y avait 11 serveurs de prévu). Et là, avec des contraintes pareilles le developement se ferait en c avec oracle comme base de données sur du materiel UNIX et que tous les serveurs serait doublés ainsi que le site de production.
Le jour où un prestataire de service dira pour ce genre d’astreintes il préconise XCode sur MacOSX sur des Xserve a ce moment la on aura une vrai stabilité de la plate-forme de developement Apple. En attendant je choisis Java.
DomreiRoam
, le 03.08.2005 à 09:55
guillôme, je viens de passer une base de donnée Filemaker de 5 à 7. Entre la 5, 5.5 et 6 aucun problème, le format de fichier est le même. Avec la 7 tout est revu. Il y a d’ailleurs quelques corrections à apporter, mais ce n’est pas très long. Par contre, il y a un méchant bug. Avant, quand depuis la base A on exécutait un script dans la base B, le fichier de la base B passait au premier plan et si c’était un sous-script, à la fin, en revenant dans la base A, celle-ci passait au premier plan. Maintenant, ça ne fonctionne plus comme ça. Il y a une nouvelle instruction de script qui dit de passer tel ou tel fichier au premier plan. Le bug, c’est que lors de la conversion, cette intruction se place APRÈS la commande d’exécution du script alors qu’elle aurait dû être AVANT. Autre bug, les fiches liées, si elles n’ont pas été validées (curseur cliqué hors d’un champ), ne se mettent pas à jour, l’utilisateur a l’impression que ça n’a pas été fait et il crée à nouveau une fiche liée. Il faut donc ajouter des instructions de validation dans les scripts de navigation. Un peu la galère, ça m’a pris 5-6 heures avec une base de 17 fichiers, env. 500 rubriques et 300 scripts. Mais la 7 ouvre des possibilités et nécessite moins de « jongler » avec autant de fichiers que la 6, mais on se retrouve dans la même situation que les développeurs d’applis, tout réécrire pour optimiser.
, le 03.08.2005 à 10:03
Sparhawk, tu viens de résumer le problème potentiel que je sentais venir :(
Bon pour l’instant tout va bien, mais quand je vais faire la transition 5.5 vers 8 (ben oui, sur MacTel ce sera la 8?), je sens qu’il va y avoir des dégâts :'(
, le 03.08.2005 à 10:05
Bonjour à tous..
A lire ce qui est écrit ici, moi qui ne suis pas un adepte d’Apple, je ne peut m’empêcher de sourire..
Que n’a t’on entendu sur la volatilité des versions de Windows, des abus (réels et insupportables) de Microsoft..
Je voudrais juste signaler à cette communauté de développeurs Macophile (je suis moi même développeur indépendant, et même que c’est mon métier, et même que j’en vis, et même plutôt pas mal), que j’ai commencé à developper sous Windows 3.11 en 1993, avec un environnement de développement qui s’appelle Windev. Et bien mes programmes tournent toujours sous XP, avec quand même quelques recompilations. Et en plus, je génère des exécutables qui tournent sur Mac..
Allez c’était juste pour alimenter la polémique Mac vs PC..
Bons développements à tous..
, le 03.08.2005 à 10:43
Il faut être honnête, il y a du vrai dans ce que dit Claude Mouginé.
La transition OS9 vers Os X est plutôt radicale.
Le changement du 68000 au PPC est plutôt violent pour le code bas niveau.
La volatilité des api Mac OS X qui ne sont stabilisées que depuis Tiger est source de problèmes!
Le futur changement du PPC à Intel va « tuer » les applications carbon et nécessiter une refonte pour les instructions bas niveau.
De l’autre côté, des programmes conçus pour W3.1 ou DOS continuent à fonctionner sous XP :O. Etonnant mais bient pratique quant on a des petits programmes dont on ne peut pas se passer!
Le processeur est depuis l’origine x86 sauf des petits errements coté Alpha et les api évoluent mais les anciennes restent.
M$ l’a bien compris en soignant aux petits oignons ses développeurs et en créant ainsi une bibliothéque logicielle immense par la rétro-compatibilité.
Côté Apple, c’est plutôt, on jette tout et on recommence… Mais Apple semble avoir pris la mesure de ce problème : ses initiatives envers l’OpenSource, un vrai IDE avec XCode gratuit, le support de tous les langages grâce à la couche unix… Tout cela me donne confiance et c’est pourquoi je me suis lancé dans Obj-C/Cocoa :)
, le 03.08.2005 à 11:14
C’est malheureusement tout à fait vrai. Certaines applications Carbon, par exemple celles traitant des fichiers binaires comme des images ou de la vidéo, seront plus ou moins difficiles à porter pour MacTel que cela soit avec Xcode ou des outils MW qui n’existeront jamais.
Je parie qu’une application comme Graphic Converter, par exemple, ne sera pas convertie en quelques heures comme le ferai un développeur d’une appli Cocoa qui ne fait que des appels au framewors, pour simplifier.
Le changement d’architecture et le passage au little endian donnera du travail au développeur s’il ne l’avait pas prévu initialement… et les oublis (conversions little/big endian) ne sont pas signalés lors de la compilation, ce n’est qu’à l’exécution que l’on constaste le problème.
Il m’a fallu 12 heures de labeur pour migrer un projet de taille moyenne CW/PowerPlant (target Mach-O) de CW à Xcode 2.1 PPC, ceci en sachant que Xcode est capable de récupérer la structure du projet CW.
Au final, l’exécutable final optimisé est 2x plus gros (le linker de CW est bien meilleur que celui d’Apple mais Obj-C et C++ sont bien différents).
Je ne vous parle de mon essai de compiler pour Intel… plusieurs milliers de warnings. Conclusion, je ne porterai pas cette application pour MacTel en mode natif.
Il est clair qu’Apple pousse à développer avec leur outils et à abandonner Carbon au profit de Cocoa et d’Obj-C++.
Espérons que GCC pour Intel et Xcode se bonnifie avec le temps. Sinon j’aurais l’impression d’avoir échangé mon cheval de course par un boeuf dopé!
–SOS
, le 03.08.2005 à 11:53
Claude Mouginé: mais je te rassure, sur Mac, certains développeurs ont juste eu à recompiler leur soft, comme toi, et cela marche depuis plus de 10 ans.
Le problème, globalement, ce n’est pas tellement ça.
Je veux dire, si on demandait aux développeurs de porter leur(s) application(s) sous une nouvelle plateforme pour gagner 50% ou même 200% de performances, ils seraient ravis.
Le problème avec Apple c’est que si ça fait 20 ans que tu développes pour eux, tu as tout simplement migré et donc fait des investissements financiers plus ou moins importants dans un seul but: rester sur la plateforme.
C’est pas très porteur pour une société qui dans le fond doit gagner de l’argent avec ce qu’elle développe.
Après tout le monde s’étonne que ces boîtes demandent de l’argent lors d’une migration qui n’apporte rien de plus à part un logo du genre « optimized for PPC » et dans quelque temps « optimized for Intel ». Je salue au passage mes camarades qui utilisent Adobe, ils se reconnaîtront.
C’est ça, je pense, que François voulait dire par « ne nous laissez pas tomber ». Si j’étais une grosse boîte je me dirais: bon, c’est la 3ème grosse migration qu’on doit se taper et je ne sais pas si Apple, tout d’un coup, se lancera sur mon terrain (salut aux gars de CodeW, Premiere, etc.)… est-ce que ça en vaut encore la peine?
La seule boîte qui a eu de la chance dans cette histoire, c’est la société Logic qui c’est fait rachetée au lieu de voir Apple sortir un soft directement concurrent…
T
, le 03.08.2005 à 12:34
Il se passe le même genre de choses de l’autre coté :
Aujourd’hui, l’OS doit être capable de faire plein de choses « out of the box ». Donc, m$ livre movie maker, qui marche sur le territoire de Pinnacle , m$ livre msn messenger qui bousille tous les concurents …
Si apple ne faisait pas ça, aussi, beaucoup de gens diraient « c’est un OS archaïque, on peut rien faire avec ». Donc, apple fait, histoire de pouvoir continuer a parler du « most advanced OS ever ». Et forcement, ils marchent sur les plates-formes des autres …
Pour les migrations, c’est vrai que c’est plus délicat … mais franchement, Apple avait-il le choix ?
Et puis en regardant
– apple a fait une rupture au niveau logiciel, et à choisie des bases solides, ce qui devrait assurer une certaine pérennité
– apple a fait une rupture au niveau hardware, et la encore a choisie la solution qui sera probablement la plus stable
Avec les API de Tiger qui sont figées, je pense sérieusement que on est parti pour une période de calme plat (avec des évolutions, mais plus de révolutions du genre os9->X, ppc->x86).
, le 03.08.2005 à 13:06
un peu hors du sujet, désolé…
une petite question à Claude Mouginé:
tu dis que Windev peut générer des appli tournant sur Mac ???
A partir de quelle version (de Windev) ?
Merci
Filou
, le 03.08.2005 à 13:57
Chuis assez d’accord avec ToZiEnd (one more time, on est bon pour se pacser, grand fou !).
Comme dirait Okazou, l’argent, c’est le nerf de la guerre. Avec ce genre de révolution, une boîte qui développe et vend sur mac se doit de gérer des budgets, des améliorations et corrections logicielles, des retours sur investissement des versions précédentes… Alors ajouter le maintien sur cette plateforme, surtout après 68>ppc, os9>osX, ppc>intel à présent (comme à chaque fois c’est la dernière j’vous jure !), au regard des pdm d’Apple et des ventes à espérer, le risque c’est de jeter l’éponge et d’aller sur une plateforme avec une plus grosse pdm et/ou plus rassurante question environnement de développement.
Non, me tromperais-je ?
, le 03.08.2005 à 14:19
Tu ne te trompes pas. D’un autre côté, le même phénomène par effet de bord écrème en quelque sorte les développeurs mac en décourageant les « besogneux » au profit des « passionnés ».
On est tous d’accord sur le fait que les « vrais » travailleurs « sérieux » ont « droit » à leur confort, mais le fait est que si les employés de Lotus pensaient comme ceux de Renault, ils fabriqueraient des Renault, ce qui serait triste pour les amateurs de Lotus.
Si tu te demandes pourquoi les portages mac vers Win ont du succès et jamais le contraire, c’est juste ça.
(correction : à part SketchUp, bien sûr, à part Sketchup. Qui fait l’objet d’un mode de développement « normal » pour nous qui n’a pas cours sur les autres plates-formes, selon l’un de ses développeurs )
, le 03.08.2005 à 14:33
Merci VRic. Mais justement, avec une plateforme MacIntel bootable sur Windows, n’y a t’il pas risque supplémentaire d’encourager la « paresse » de certaines boîtes et de marginaliser un peu plus la plateforme Mac ?
, le 03.08.2005 à 15:27
Je ne pense pas. C’est vrai que c’est ce qui a tué OS/2, mais la situation n’est pas comparable. Apple dispose déjà d’une base de quelques millions de clients et généralement assez fidèles à la marque.
D’un autre côté, il ne faut pas oublier que la plus grande partie des gros programmes existent sur les 2 platteformes, mais la présence d’un processeur commun va réduire les coûts de développement.
>guillôme: tu as pensé à CoreData pour remplacer ta base FileMaker? Il y a moins de chances que Apple laisse tomber ça que FileMaker non? Et puis tant qu’à tout réécrire ;)
, le 03.08.2005 à 15:35
Bien sûr, mais d’un autre côté mets-toi à la place du commercial essayant de vendre le machin : comment tu expliques au gugus qu’il doit t’acheter un truc qui l’oblige à redémarrer à chaque fois qu’il veut s’en servir en arrêtant donc tout ce qu’il était en train de faire et en se passant de tout ce pour quoi il a choisi un mac ?
Tu n’as une chance d’y arriver QUE s’il tu n’as aucun concurrent. Et encore, si tu te permets ça, tout éditeur sérieux se transformera vite en concurrent vu l’opportunité de t’évincer « facilement ».
Il y a eu un soft de CAO dans ce genre. Constatant la forte majorité du mac chez les architectes à l’époque, ils ont fait une version mac. Le machin était techniquement très avancé, mais son interface était ridicule (ils le croyaient facile d’utilisation puisqu’il y avait plein d’icônes sur plein de boutons) et le portage mac si incroyablement mauvais qu’en plus de sa lenteur phénoménale le moindre utilisateur avancé savait comment expliquer au développeur que puisqu’il a « compris » le fonctionnement des ressources, alors il n’a pas besoin des 10 ou 12000 mini fichiers en plus de l’application et surtout que oui on peut demander de la mémoire temporaire sur mac (c’était vers 95, le mythe c’était que non), mais non il ne faut pas la prendre dans le heap système, c’est une autre instruction pour les applications, et non il ne faut pas le faire au lancement, sinon pas de raison de l’appeler temporaire, et non il ne faut pas prendre TOUT moins 4 Mo, sinon on ne peut rien lancer d’autre, etc. Résultat leur machin était suffisamment inutilisable pour qu’ils aient du mal à le vendre. Leur conclusion: le marché mac n’est pas porteur. Moi je dis: tant mieux.
, le 03.08.2005 à 15:49
oui et non … les jeux écrits sous DOS fonctionnent pas toujours très bien sous XP (en particulier avec le son qui déraille…).
Et que dire des programmes écrits sous Windows de 1.0 à 3.0 ? Ben, ils ne sont plus du tout compatibles… Je me rappelle d’un traitement de texte qui fonctionnait bien sous Windows 3.0 et 3.1, mais plus sous NT 4.0 …
Pas forcément le dualboot qui a tué OS/2, mais c’est en fait la compatibilité bien trop parfaite avec WinOS/2 (une émulation de Windows 3.1), ce qui avait rendu « superflu » le portage en natif d’applications.
, le 03.08.2005 à 15:50
Et au fait, comment tu justifies de t’acheter disons un soft de comptabilité à 50 Euros PLUS Windows ? Quelqu’un a regardé le prix de Windows ? C’est loin des 129 Euros de Mac OS dont tant se plaignent déjà (d’accord MS met à jour moins souvent, mais ça ne va quand même pas devenir un argument de vente).
D’ailleurs mets-toi maintenant à la place du joueur : en gros pour le prix de Windows il peut avoir une console de jeux. Pourquoi il s’emmerderait à le dépenser pour quelque chose qui interrompe le fonctionnement de son mac ?
Alors c’est sûr que ça va convaincre des gens et qu’il y en aura pour le faire (il y a bien eu un marché florissant du lecteur de disquette USB après l’iMac). Mais ça reste con et 2 ans après c’est définitivement du gaspillage qui dort dans un tiroir.
, le 03.08.2005 à 16:34
Oui mais encore une fois, une boîte qui rend des comptes à des actionnaires devient vite frileuse quant à prendre le risque financier d’un portage ou un maintien sur la plateforme Mac au vu des pdm. Au pire, ils rétorqueront qu’un re-boot sur la « bonne » plateforme vaut mieux que rien du tout. De même pour l’argument du concurrent, la pdm délimite rapidement le potentiel sur Mac. Je me fais un peu l’avocat du diable là, en espérant me tromper.
, le 03.08.2005 à 17:57
Savez-vous qu’au XVIIIe siècle, lorsque fut inventé la mèche plate enroulée, l’augmentation de luminosité était telle qu’un commentateur à écrit : « c’est de la folie, avec de telles lampes tous les jeunes seront aveugles avant d’atteindre mon age! ».
Les gens qui avaient investi dans des lampes à mèches simples ont du apprécier…
C@naille (!)
, le 04.08.2005 à 08:21
Réponse à Filou53 :
A partir de la version 9, Windev s’est sérieusement enrichi :
– Prise en compte de la modélisation UML pour générer le M.L.D.
– Client serveur sous Win ou Linux
– Code identique pour développer des applis classiques, des applis Web et des applis Pocket PC (et malheuresement pas PalmOS)
– Exécutables générés en C++ ou Java, (.Exe ou .Jar)
Faites un petit tour sur le site de PCSoft (l’éditeur) pour en savoir plus (www.pcsoft.fr)
A votre disposition en cas de besoin..
, le 04.08.2005 à 12:04
Salut :-)
Comme j’ai pu le dire sur MacG, je trouve que c’est toujours l’utilisateur/consommateur final qui pâtit lorsqu’il n’a qu’un seul choix (non-sens !?) possible, et la disparition de CodeWarrior, même si, comme certains semblent l’affirmer, il n’était plus vraiment au goût du jour pour certaines spécificités de OsX, je pense que c’est quand-même une alternative sérieuse qui s’en va.
D’ailleurs, je ne comprends pas pourquoi Apple ne s’implique pas d’avantage pour soutenir et aider ces quelques acteurs historiques majeurs de notre plateforme ?
Il me semble que, à terme, c’est dans son intérêt que ces applications, qui ont connu un certain succès auprès des utilisateurs, puissent perdurer comme des valeurs sûres sous OsX…
Bref, XCode et les outils de développement fournis gratuitement par Apple semblent être de très bonne facture, mais, peuvent-ils encore évoluer à bon rythme sans une émulation concurrentielle saine ? … nous verrons…
En tout cas, gageons que d’autres éditeurs proposeront bientôt (lors du MacTel ?) des outils puissants et compétitifs… juste histoire que notre choix ne soit pas restreint à une seule et unique alternative (<- fait exprès ;-).
Fredo d;o)
« Un pas à la fois me suffit… » (Gandhi)
, le 04.08.2005 à 12:57
> Claude Mouginé:
Grand merci pour l’info.
Filou53
, le 09.08.2005 à 10:29
XCode sera toujours en concurrence (Eclipse par exemple), la mort de CodeWarrior ne changera pas son évolution.
Par contre, pour garder les développeurs mac et en convertir, je ne vois pas 1000 solutions. La plus simple serait de permettre aux applications Cocoa de tourner nativement sous Windows. C’est déjà en partie possible (Cocoa est un API très souple niveau plate forme supportée) et si Apple continue sur sa lancée de reconquête des PDM, elle pourra convaincre de grands éditeurs, comme a toujours su le faire, pour développer en cocoa.
Je sais, ça parrai stupide, mais le frein le lus important à « .net » c’est qu’il n’est pas multi-plateforme.
Ho, je compare 2 choses qui n’ont rien à voir. mais l’abandon de Cocoa-Java va dans quel sens ? Abandon du pont vers Windows et Linux, ou au contraire rénovation de ce pont ?
Il y a peut être d’autre solution pour éviter que les logiciels Mac se retrouvent en concurrence avec les milliers de logiciels mal foutu* sous windows. Mal foutu*, mais si facile à trouver !
Mais si Apple n’en trouve pas une, beaucoup de perles vont devoir se retirer de la scène.
* Mal foutu -> Sous OS X ces logiciel tourneront via une émultation du système de fenêtrage, ça marchera comme X11, bien, mais pas de façon homogène avec Mac OS X.
, le 11.08.2005 à 13:39
> J’ai lu sur Mac Génération que CodeWarrior décidait
> de jeter l’éponge, et ne fera plus évoluer son
> environnement de développement pour la plateforme
> Mac-Intel.
J’allais te rassurer quand j’ai realise que ceci:
http://www.codeweavers.com/about/general/press/?id=20050809
N’avait RIEN a voir avec le sujet.
Sorry:(
@ Work || @ Home