Ressources système API Windows, comparées à Mac

Citation:

---

Envoyé par Mac LAK

Bon, on va donc résumer : toi, tu bosses sur des applications de quelle taille ?

Moi, ce sont des centaines de milliers de lignes de code, sur des applications distribuées, portables, tournant sur 3 à 6 OS différents, multi-langages, ayant des composantes temps réel, réseau, stockage et calcul intensif, et avec une équipe qui oscille entre 20 et 40 personnes dessus. A temps plein. Puisque tu veux parler argent, un système complet vaut quelques MILLIONS d'euros, et c'est garanti 15 ans.

Alors les problèmes d'intéropérabilité, de portage, de deadline, de maintenance, de coût, de gestion des obsolescences et d'évolution, ça va, je maîtrise, j'en bouffe au quotidien depuis dix ans. Et vu le prix qu'y mettent mes clients, ça ne les rend pas spécialement tolérants aux bugs : ils paient pour assurer une fonction pendant 15 ans, quoi qu'il arrive, quoi qu'il se passe. Et réécrire en natif une appli, c'est la porte ouverte aux régressions, différences de comportement, et dérives de code. Bref, un joli trou sans fond où l'on pourra jeter plein de sous.

Relis un peu mieux ce que j'écris : non, je ne critique pas ta chère API, je tente (vainement apparemment) de t'expliquer qu'elle n'est PAS la panacée universelle que tu sembles croire, qu'elle a AUSSI des faiblesses, et qu'on ne réalise pas un portage d'application en réécrivant tout en natif (pas si l'on veut maintenir le logiciel dans l'avenir, en tout cas). Ni plus, ni moins.


Définitivement, nous n'avons pas la même notion de ce qu'est un portage, ou une application portable...


T'inquiètes, j'ai terminé... ;)

Par contre, si jamais tu as l'occasion d'essayer Lazarus de façon un peu intensive, je suis intéressé par un retour d'expérience.

---

vos "on ne fait pas ceci, on fait pas cela…" sont puérils…
"Tant que la régle vous pèse, c'est que vous en avez besoin." Maurice Merleau-Ponty

La seule chose que je dis est que dans NOTRE contexte, NOTRE méthodologie de "portage" montre que des avantages indéniables aussi bien techniques que financiers… et qu'il y a des "plus" côté développement Cocoa/IB/Objective-C++…
Y-a-t-il des inconvénients ? Certes, mais pas au point de renverser la balance…
A-t-on été confronté à des manques dans les APIs disponibles sur Mac au point de prétendre que ce soit "moins riche" et que l'on vienne pleurer dans mon bureau pour me dire "C'est pas possible…" ? Non…

Est-ce que cela implique que ce soit ainsi pour tout le monde ? Certainement pas…
Vous faites autrement et vous en êtes content ? Grand bien vous fasse…

Je suis pourtant d'accord avec Mac LAK ici: Si on remplace Delphi par Java, on voit encore plus la question:
Quel est l'intérêt de convertir de "Java sous Windows avec des appels vers des bibliothèques Microsoft" vers "C sous Unix" plutôt que vers "Java sous Unix avec des appels vers des bibliothèques GNU" ?
Cet intérêt est-il vraiment supérieur aux coûts?

Il se trouve simplement que le portage (et la portabilité) sont des éléments clés de mon travail, donc comme je le disais précédemment, ça va, je connais le problème. Cela ne m'empêche nullement d'utiliser AUSSI des API natives, simplement, je sais quand les utiliser à bon escient, et au contraire quand il faut passer par une couche portable... Notamment lorsque l'on doit mettre en balance la pérennité des applications.

Et pour ma part, si un dév se pointe en me disant "pour porter l'application, on casse tout et on redéveloppe", je le crucifie direct, car je l'entends comme "on va faire un double développement, exploser les coûts de maintenance et de tests, et risquer des régressions à chaque livraison".

Citation:

---

Envoyé par JeitEmgie

"Tant que la régle vous pèse, c'est que vous en avez besoin." Maurice Merleau-Ponty

---

"Tant que la règle vous pèse, c'est qu'elle est mal conçue.". Moi.

Une bonne méthodologie de développement doit s'intégrer de façon fluide et naturelle dans le processus de développement, et non pas s'intégrer comme un cheveu sur la soupe, carboniser des heures en procédures procédurières pour un résultat final souvent discutable.

Je suis le premier à dire que, parfois, il est nécessaire de réinventer la roue pour atteindre l'optimal, surtout quand le client paie pour cet optimal. Cependant, je suis également le premier à dire que refaire du code "presque pareil" est la plus grande stupidité possible, car c'est un signe de manque de factorisation ou de portabilité.

Et réécrire du code natif pour chaque "portage" fait partie, en règle générale (cf. § suivant), des pertes de temps inutiles et coûteuses.

Citation:

---

Envoyé par JeitEmgie

La seule chose que je dis est que dans NOTRE contexte, NOTRE méthodologie de "portage" montre que des avantages indéniables aussi bien techniques que financiers…

---

Ah, je suis content que tu aie enfin pris conscience que c'est TA méthodologie et TON contexte de "portage" (notons les guillemets). Bien que ce ne soit pas parfaitement exact, car tu disais initialement :

Citation:

---

notre expérience du "portage" Windows -> Mac est que l'API Cocoa nécessite moins de lignes pour faire plus,
et que l'architecture des frameworks est beaucoup plus importante que le nombre de méthodes disponibles.

(et par moins de lignes il faut comprendre des réductions jusqu'à 40% dans certains cas…)

donc on pourrait dire par analogie gastronomique : ne pas confondre "richesse" et "mauvaise graisse"…

autre élément à tenir en compte : réécrire va plus vite qu'essayer de récupérer du code pour tout ce qui concerne l'interaction avec l'utilisateur… ne gardez que le code de pur "calcul" (au sens large…)

---

Sauf que ce n'est pas le contexte "normal" d'un portage, un VRAI portage, et que c'est ce contexte "normal" qui est compris et utilisé par l'immense majorité des dévs, lorsqu'ils parlent de "portage d'applications".

Donc, je te concède bien volontiers que dans TON cas, cela peut être un calcul intéressant de tout réécrire : c'est toi qui a les comptes sous le coude.

Merci de bien vouloir avoir l'élémentaire politesse d'admettre que ce n'est PAS le contexte général d'un portage, et qu'il est possible de gagner encore plus en capitalisant au maximum le code sans sacrifier pour autant à la qualité finale du produit...

En effet, entre 200.000 lignes de code wrapper/template pouvant être testées automatiquement en non-régression / double comparaison [cas d'un portage] et 10.000 lignes de code totalement spécifiques devant être testées "à la main" [réécriture], je sais ce que je choisis : les 200.000 lignes de code ne coûteront pas le dixième du coût du "spécifique", en maintenance comme en test... Quand il n'est pas carrément possible de générer automatiquement les wrappers, en plus, ce qui fait alors chuter drastiquement le temps de développement lui-même.

Et s'il y a bien un domaine où l'optimal n'est pas de mise, c'est bien les couches de présentation (les IHM, donc) : le redéveloppement n'offre donc en général aucun intérêt. Cela n'est nécessaire que sur les parties devant être optimales, donc le "calcul pur", chose que tu préconises au contraire de garder "telle quelle". Bref, tu fais l'inverse de ce que l'on fait dans un portage normal...

Citation:

---

Envoyé par Médinoc

Je suis pourtant d'accord avec Mac LAK ici: Si on remplace Delphi par Java, on voit encore plus la question:
Quel est l'intérêt de convertir de "Java sous Windows avec des appels vers des bibliothèques Microsoft" vers "C sous Unix" plutôt que vers "Java sous Unix avec des appels vers des bibliothèques GNU" ?
Cet intérêt est-il vraiment supérieur aux coûts?

---

et où aurais-je suggéré cela ?

Une application Java standalone, quelle que soit la plate-forme sur laquelle elle tourne, est rarement un exemple d'inventivité ou de fluidité en termes d'UI et l'intégration avec son environnement est souvent peu aboutie… donc en partant du principe que si le Java a été choisi dans ce cas c'est à bon escient, on peut en déduire que la clientèle de ce genre d'applications s'en contente… ou n'a pas le choix…

Les problèmes de ce genre d'applications commencent quand elles doivent réellement lutter pour se faire une place dans un marché particulier et que la clientèle a le choix…

Eh bien pour Delphi+VCL, c'est la même chose.
Quand on a déjà quelque chose qui tourne sur une plate-forme un minimum portable, inutile de tout réécrire avec une technologie spécifique pour la plate-forme de destination...

Citation:

---

Envoyé par JeitEmgie

Une application Java standalone, quelle que soit la plate-forme sur laquelle elle tourne, est rarement un exemple d'inventivité ou de fluidité en termes d'UI et l'intégration avec son environnement est souvent peu aboutie…

---

Citation:

---

Envoyé par Médinoc

Eh bien pour Delphi+VCL, c'est la même chose.

---

Humm... Plus discutable, ça : Delphi est parfaitement capable de taper "bas niveau" dans Win32 de façon très simple, chose plus difficile à faire avec du Java, et est parfaitement capable d'être donc très intégré à l'OS, tout comme d'être orienté système.

Je ne dirais donc pas "c'est la même chose", mais plutôt "c'est encore pire" : si l'IHM est à peu près portable, le code d'intégration, lui, ne l'est pas du tout. C'est bien pour ça que je parlais de wrapper la partie Win32 sur les autres OS.