Discussion :

[Invité]

Bonjour,

[NDLR : Ce débat fait suite à ce sujet sur le développement pour Android en Pascal.]

A mon avis Java est la solution actuelle [NDLR : pour le développement Android]. Elle fonctionne sans complication.

J'en profite pour demander à bénéficier de votre avis argumenté... et reprendre le fil de ma pensée :

D'ailleurs pour l'équivalent de "nos" exe, j'ai la même impression : avec mon manque de connaissances en Java, même si je pratique assidûment depuis 6 mois, la résolution de mes incompétences nécessite moins de temps que les difficultés que je rencontre en Lazarus... et ceci sans l'aide d'aucun forum. J'ai acheté une 1/2 douzaine de livres sur le sujet, édité des tutos et utilise une vraie documentation intégrée... Et c'est fabuleux de pouvoir faire cela pour un actuel Pascalien. En Lazarus, j'utilise toujours le livre de Paul, la documentation Delphi 7, et erre sur Internet dans les labyrinthes lazarusiens. J'avais oublié le plaisir que m'apportait Delphi 7 à ce niveau. Qu'il s'agisse de Lazarus (et de FMX quand je l'ai essayé), c'est réellement une frustration.

Début juillet, j'ai démarré un développement "Emplois du temps flottants". Après les simulations de rigueur et la formalisation du projet, le matin est consacré à une version en Lazarus, l'après-midi en Java. Il n'y a pas photo : j'ai utilisé l'avance que j'ai "dégagé" en Java pour modéliser mon approche Lazarus au point que c'est moi qui flotte : je demandais, il y a quelques jours sur ce forum, comment gérer mes Forms... Visiblement l'approche Java m'imprègne.

Bref, en ce qui me concerne, je crois que mon utilisation de Pascal touche à sa fin. La lucidité et probablement la lassitude m'amènent à cette conclusion. J'ai failli prendre cette décision, il y a 2 ans. Je n'en ai pas eu le courage : remettre en cause un apprentissage débuté en 1983 avec Turbo Pascal, c'est quand même quelque chose ! Je prendrai la décision fin juillet mais je résume, j'espère honnêtement, en tout cas sans aucune amertume :

• Exécutable multi-OS : Avec Lazarus, malgré ma propre bibliothèque d'une trentaine de composants corrigeant la transaction mySQL buguée avec les natifs, les problèmes d'affichages et d'ergonomie différente entre Nux et Win, de gros problèmes d'UTF8, sans parler de bibliothèques complètes ne fonctionnant pas en 64 bits, des composants mal finis ou très incomplets (TStringGrid), et évidemment des mises à niveau de l'IDE quotidiennes ou presque, j'ai passé plus de temps "à côté" de mes projets que dedans... Avec Delphi, FMX, je ne situe pas exactement. C'est prometteur mais sans Doc... et pas encore Nux.
• Plateforme Internet : Lazarus rien (ou https://github.com/rnapoles/PHP4Lazarus, mais je n'ai pas réussi à obtenir quoi que ce soit). Delphi4PHP (devenu RADPHP), je l'ai essayé avec mon Delphi 2007 (tous les 2 ans, j'ai investi dans une plateforme "Education", histoire de soutenir modestement l'évolution... mais 2007 fut la dernière) : je l'ai ressenti comme un carcan. Le rapport contraintes/apports m'a semblé très défavorable mais cela doit être lié à ma manière de pratiquer le php.
• Androïd : Lazarus idem non exploitable selon mon expérience. Doc anémique. Envergure des exemples tant autant : j'ai bien essayé d'afficher hello Word... Quand on est obligé d'y passer 2 jours pour obtenir un non-résultat, il vaut mieux remettre immédiatement en cause son "adéquation de programmeur avec l'outil employé". C'est une manière un peu compliquée de s'exprimer, mais bon... restons dans la nuance. la solution Embarcadero, si j'ai bien compris, utilise un "morceau" de Lazarus/FPC...

Alors il est vrai que FMX me tente et que finalement attendre un an ou deux de plus, c'est jouable en ce qui me concerne. Mais, j'ai redécouvert un vrai plaisir de développer avec Eclipse/Java et Netbeans/Java. Un plaisir qui m'a rappelé celui que m'apportait Delphi 7. Choix difficile donc.

Votre avis de Lazarusien ou de Delphien (Delphiste ?) m'intéresse. La part entre la lassitude et le pragmatisme est difficile à cerner. D'un autre côté, il se peut que j'utilise mal Lazarus...

Mon développement en Pascal a toujours été sans concession. Je peux me le permettre car je ne vends pas... Voir un exécutable se figer alors qu'il est en langage compilé parce qu'il n'a pas été threadé me gêne (accès aux BDD ou divers services FTP,...)... et après on vante la supériorité en terme de vitesse du compilé sur l'interprêté (et la machine virtuelle). Hum... Avec Lazarus, voir une version Linux ergonomiquement inférieure à la version Windows sous prétexte que les widgets natifs seraient eux-mêmes inférieurs ou plus probablement parce que les composants ont été développés sous Windows ou fortement extrapolés de ceux de Delphi 7 et plus ou moins bien adaptés, me consterne tout autant. Allez dire à un Linuxien que son OS est ergonomiquement inférieur à Windows. Je pratique les 2 tous les jours et j'apprécie autant l'un que l'autre... et ne constate rien de tel !

Bref, si vous avez des réflexions sur la pertinence de continuer à programmer en Pascal compte tenu de mon approche évidemment, j'aimerais en profiter.

Quitter le Pascal comme je l'ai écrit n'est pas une décision facile à prendre. D'avance, grand merci.
Bon WE. Cordialement. Gilles

[ChPr]

Pour ce qui me concerne, j'ai appris le Pascal en 1978 aux USA pour programmer une machine à régler les résistances par dépôt sur substrat.

J'étais électrotechnicien/électronicien et n'avais jusque là jamais tâté de l'informatique. Je me suis mis assez aisément au Pascal parce que sa structure est celle qui ressemble le plus à notre langue écrite et c'est pour cela que j'ai progressé dans ce domaine : Turbo Pascal, langage objet avec Delphi 1 à 6 puis passage à Lazarus parce qu'il me permettait d'aborder les deux environnements Windows et Linux. Pour autant, Lazarus sans la doc de Delphi 6, c'est ... je ne trouve pas mots !

J'aime ce langage. Rien qu'à voir du C, C++, Java, ça me donne des boutons . J'ai l'impression d'être devant une table de hiéroglyphes.

Mais bon, lorsque les outils sont "improbables" ou d'une complication telle qu'on passe plus de temps à les comprendre/utiliser : je commute (j'avais déjà reproduit partiellement un programme de traitement d'images en Java).

Pour mes applications sur PC, je vais rester avec Lazarus. Pour Android, je me suis mis à Eclipse et l'émulateur Android. Ce n'est pas trop compliqué, il y a beaucoup de doc sur le net, mais qu'est ce que c'est long !

Je vais rester vigilant et si possible, je reviendrai à Lazarus pour Android.

Cordialement.

Pierre

[tourlourou]

Bonjour,

Je ne suis pas (encore ?) confronté aux problèmes de multi-plateformes à ce point, et la plupart de mes codes sont à mon usage exclusif.

Le manque de documentation sous Lazarus est préjudiciable, mais l'intégration dans CodeTyphon apporte un plus à ce niveau. Et les heureux possesseurs de vieux Delphi (5 à 7) disposent d'aides dignes de ce nom. Sinon, doc en ligne...

Rendu sous Linux : mérite certainement de progresser !

Java : connais pas (encore ?). Mais ce que je connais d'autres langages (Basic, C, C++) me conforte dans la conviction que le Pascal est un langage structuré idéal pour l'apprentissage (voici un argument pour un enseignant !!!) et la lisibilité. Le lien avec l'assembleur reste possible aisément (mais difficultés du multi-plateformes) ce qui a un intérêt didactique plus que pour l'optimisation, compte tenu de l'efficacité de la compilation, et à titre de casse-tête ou challenge. Pour autant, si on peut "tout faire" comme en C, ce n'est généralement pas au détriment de la compréhension du code, grâce à un typage plus fort et des habitudes d'écriture plus saines (?).

Dans le cadre de ta problématique, quitter le Pascal est peut être une solution, mais sans oublier les bonnes habitudes prises en programmant en Pascal !

Pour ma part, je m'essaye à Lazarus et attends un futur Delphi plus large d'assise.

[Simicro]

J'aime ce langage. Rien qu'à voir du C, C++, Java, ça me donne des boutons . J'ai l'impression d'être devant une table de hiéroglyphes.

Bonsoir,

Oui, je partage pour les boutons face au C, Java, etc. Rien qu'à voir la "gueule" du code, ça ne donne pas envie de s'y mettre

Moi aussi j'aime le Pascal pour les qualités qu'on lui attribue habituellement et donc pour sa "beauté"

Je me suis mis au développement vers fin mai de cette année après avoir fait une petite étude sur les langages disponibles. J'ai bien vu que Pascal / Delphi / Lazarus était minoritaire comparé aux autres langages mais j'ai quand même craqué ! Et puis ce sont des produits qui sont chargés d'histoire : Turbo Pascal... Borland... les innovations... Delphi... le paradigme de l'IDE et du RAD créé en grande partie par Borland... Bref, ça me rappelle un peu les années 80 lorsque j'ai choisi de démarrer la micro-informatique avec un Apple II !

[skywaukers]

Bonsoir,

Pour moi aussi, le Pascal reste le langage le plus clair et le plus agréable à utiliser. C'est vrai que pour le multiplateforme ce n'est pas top. Mais l'arrivée de FMX me semble très prometteuse.

La documentation est foisonnante sur Java certes, mais faites essentiellement pas les utilisateurs. Il faut croire qu'il sont plus altruistes que les développeurs Pascal donc.

Par contre je voudrais rebondir sur ton explication de programme natifs qui se figent et qui sont moins performant que des langages interprétés ! Par quel miracle les langages interprétés ou les langage avec machines virtuelles ne figent pas ? Dis plutôt que avec ces langages tu n'as pas à gérer cela, mais stp ne prend pas l'exemple d'un code écris n'importe comment pour affirmer qu'un code natif ne serait pas plus performant qu'un code interprété. Ce n'est pas qu'on vante que le compilé soit plus performant que l'interprété, c'est une réalité qu'on pourrait qualifier de logique. Après on peut par son code faire n'importe quoi.

Enfin Java et la portabilité, ce n'est pas toujours le paradis non plus, entre les différentes versions de la jvm, j'ai vu de tout simples codes java ne pas tourner sur toute les machines (toute windows qui plus est). Au moins un exe Delphi, sauf s'il a besoin de librairies tierces bien sûr, je le fais tourner sur n'importe quel PC, sans me soucier de ré-requis à installer.

@++
Dany

[Invité]

Bonjour Dany,

Je n'ai pas écrit que les programmes interprétés ne gelaient pas... mais il existe aussi des thread dans les langages interprétés.

Je suis libre d'appartenance à ces diverses catégories de langages. Je lis comme tout le monde, notamment des articles vantant encore la supériorité du compilé sur l'interprété. Et mon analyse, mon expérience, mes tests me démontrent que cette assertion n'est pas une réalité. J'aime la nuance et je me garderai bien de porter jugement sur la valeur de chacun.

Plus exigeants en ressources et la plupart du temps moins rapides à l'exécution que les langages compilés en code natif, les langages interprétés gardent toutefois un intérêt notamment par leur facilité de mise en œuvre et la portabilité des programmes, qui peuvent la plupart du temps être lancés sans modification sur toute plateforme où fonctionne l'interpréteur.
Wikipédia

A la rigueur, je veux bien recevoir l'argument que mes développements sont eux-mêmes une plaisanterie de novice... Ceci n'empêche pas que des programmes compilés et écrits par d'autres, j'en vois un grand nombre geler lorsqu'on charge une base (une dbGrid), un document (ftp)... et que j'estime que c'est assez facilement évitable... Enfin pas toujours. Je vante souvent la qualité de synapse à ce sujet comparé à Indy... par exemple qui freeze de manière inexplicable... et incontournable. Alors que vaut l'argument "la plupart du temps moins rapides à l'exécution que les langages compilés en code natif". J'aime bien cette nuance "la plupart du temps".

De bonne foi, on peut se contenter de ce qu'on a. Je me suis permis une fois d'intervenir, je crois que c'était sur un forum Delphi qui à l'époque ne compilait qu'en 32 bits alors que les machines 64 bits existaient. L'argument que j'avais lu était de dire que le 32 bits suffisait parce que le 64 bits sous Windows était plus lent que le 32 bits. Là, je crois qu'il est bon -y compris pour un Pascalien convaincu- de regarder ailleurs. Vous ne voyez que Windows et parce que Windows 7 notamment avait des problèmes au départ en 64 bits, son défaut était une justification d'immobilisme et même pire de manque d'intérêt. Alors, pourquoi ne pas être resté au 16 bits et pourquoi pas au 8 bits ?

C'est ce qui m'a séduit sous Lazarus et m'a fait quitté Delphi 7. Une bouffée d'oxygène. Ses développeurs transgressaient et s'ouvraient d'autres horizons.

Ma démarche actuelle et de savoir si une solution multi-OS (enfin c'est un bien grand mot Win, Nux et épisodiquement OS X) me conviendrait mieux que Lazarus.

Comme la plupart du temps, j'ai développé en Pascal, j'ai d'abord cherché dans cette famille :

Lazarus fonctionne mais son cheminement un peu chaotique et ses bugs redondants me lassent.

FMX, je crois que je vais l'écarter pour l'instant. Cela me fait le même effet que quand j'ai découvert C++/QT. C'est QT qui domine votre écriture. FMX, c'est vgScene où je ne sais quoi d'ailleurs : lorsque je l'ai essayé, je n'ai plus eu l'impression d'écrire en Pascal... enfin celui que je connais et que j'apprécie.

Donc depuis 6 mois, je suis allé découvrir Java. J'avais déjà fait un test mais j'étais encore trop Pascalien dans l'âme. En 6 mois, on apprend des choses, on découvre des facettes et des approches que je ne connais pas dans Lazarus, ni dans l'ancien Delphi 7 que j'utilisais. Et là, on en revient à Pascal et à XE2 et Lazarus... Mais où en sont-ils ?

Vous voulez développer Androïd ? XE2 utilise du Lazarus/FPC qui lui même est en retard. Java, cela fonctionne j'allais dire "naturellement".
Vous voulez développez de l'internet ? RadPHP et LazarusForPHP... Hum. IntraWeb... Hum.
Il y a 6 mois, un ami développeur Java m'a mis un vieux livre dans les mains "Les cahiers du programmeur" JAVA EE5- Le support du livre est la réalisation et la gestion d'un site de vente d'animaux. Le site et son back-office sont réalisés en Java. Une vieille version de Java, un portage sous Eclipse puis sous NetBeans, puis sous mySQL... J'en suis resté sur le derrière ! Une solution intégrée (en développement) avec le même IDE en Client Riche et Internet et multi-OS pour le Client Riche. Je pose simplement la question : que propose l'univers Pascalien face à cela ?

Voilà le sens de ma démarche. Comme me le dit-affectueusement mon jeune ami javaïen : Gilles tu as 5 ans de retard sur ton choix de plate-forme de développement qui a elle, 10 ans de retard sur ce qui se fait usuellement aujourd'hui. Je médite. Je m'informe. Je soupèse... et je discute.

Cordialement. Gilles

[mick605]

Une solution intégrée (en développement) avec le même IDE en Client Riche et Internet et multi-OS pour le Client Riche. Je pose simplement la question : que propose l'univers Pascalien face à cela ?

A mon avis, le Pascal n'a rien a apporter a cela. Le Pascal est, pour moi, un moyen de programmer des applications natives. Il n'a pas pour but d'être présent sur tous les plans (notamment Internet).

Pour ma part, je n'attends pas a ce que le Pascal puisse créer des sites Internet. Chaque langage est créé pour pallier a un besoin, mais tous les besoins ne doivent pas (forcément ?) être résolus avec le même langage. Après, il est vrai que sur certains points, ça serait bien pratique que le Pascal se développe, comme le multi-OS, sinon on prends le risque que le langage soit déprécié car pas assez utile.

En tout cas, pour moi, c'est très simple :
Développer pour Android ? Java.
Développer pour Windows ? Pascal.
Pour le multi OS ? Je n'y suis pas encore ...

Certains pourraient dire : Pourquoi ne pas développer également en Java pour Windows ? Il n'y aurait qu'un langage a apprendre ... Et bien parce que Delphi (l'IDE que j'utilise) m'apporte plus de facilités qu'Eclipse, et le Pascal est plus souple que le Java pour ce type de programmation.

[Invité]

Petites nuances Mick, si tu le permets.

Les environnements natifs, ils "convergent" au moins dans leur présentation, dans leurs usages... ou essaient... A terme, on ne peut pas avoir 50 OS pour les tablettes, 20 OS pour les PC, autant pour les serveurs. Des développeurs comme les Javaïens, et dans une moindre mesure, les Lazarusiens et maintenant Embarcadero l'ont bien compris. J'allais oublier les "Microsoftiens"... qui évidemment vont devoir s'adapter. d'abord, ils ont cherché à dominer le marché... Pour les PC, c'est pas mal mais pour les tablettes, ils ont encore du boulot. mais le Windows 8 n'a pas dit son dernier mot. Sinon, ils essaient d'imposer leur standard. VS, c'est bien. Je ne veux pas me laisser enfermé mais enfin il faut reconnaître que VS/C#. C'est un concepteur de Delphi qui a développé (pas lui seul évidemment) cette plateforme Microsoft... Et je trouve que les Pascaliens "natifs" (les Delphistes) auraient pu s'en inspirer. Eux, ils ont une plateforme Client Riche/Internet. Comme par hasard, il y a une machine virtuelle. Et il ne faut pas croire que Pascal n'existe que sous une forme compilée.

Pour développer sous Windows 32 bits (voire 64 mais déjà pas pour tous ses composants) jusqu'à Windows 7 inclus et les Windows servers actuels--> VCL. mais après, "ta" VCL, sous Windows 8, elle tournera en émulation, en mode compatible 32 bits ? Ou tu seras obligé de passer par FMX, si c'est la solution.

Maintenant, je ne te conteste pas ton analyse. Mais si tu as besoin de faire une application dont le back-office sera un programme natif, relié à un site internet et éventuellement avec des apports/contacts "portables" genre androïd... Et bien, il faut maîtriser Delphi, PHP et... Java. C'est de trop pour moi.

Cordialement. Gilles

[mick605]

Petites nuances Mick, si tu le permets.

Les environnements natifs, ils "convergent" ou essaient

Pour développer sous Windows 32 bits (voire 64 mais déjà pas pour tous ses composants) jusqu'à Windows 7 inclus et les Windows servers actuels--> VCL. mais après, "ta" VCL, sous Windows 8, elle tournera en émulation, en mode compatible 32 bits ? Ou tu seras obligé de passer par FMX, si c'est la solution.

Cordialement. Gilles

J'ai lu récemment que les applications compatibles Windows 7 sont compatibles Windows 8. Mais de toutes facons, je ne vois pas ce que cela change. La VCL n'est qu'une encapsulation des API système, et en programmant en Java, il faut bien s'appuyer sur des API systèmes. Le problème sera le même. Après, FMX peut aussi être la solution pour le multiplateforme. Je n'ai malheureusement pas l'occasion de tester ...

Après, ceci concerne l'IDE et le compilateur, mais pas le langage. Il y aura donc un Delphi sous Windows 8 dans lequel on programmera en Pascal ...

Edit (Tu édites trop vite ^^)

Mais si tu as besoin de faire une application dont le back-office sera un programme natif, relié à un site internet et éventuellement avec des apports/contacts "portables" genre androïd.

Je suis parfaitement d'accord, d'autant plus que je suis en train de programmer une appli sous Android, étant sensée intéragir avec un programme serveur sous Windows... Je me colle donc au Java et au Pascal.
Après, c'est intéressant de pouvoir tout programmer avec le même langage. Mais il ne faut pas oublier qu'un outil qui fait tout, fait peut être certaines taches moins bien qu'un outil spécialisé dans ces tâches là. (Je ne compare pas le Pascal et le Java pour Windows, hein, c'est général)

[Invité]

Si j'ai bien compris, la VCL qui fait appel à plein d'API win 32 tournera "nativement" (ie directement) en Windows 8. Je ne discuterai pas. Mais ce que je retiens de divers articles que j'ai lu :

Vous l’aurez ainsi compris, Microsoft nous propose un avenir en deux parties :

Applications de Consommation (gestion d’information, de données, jeux, …) avec les applications de style Métro !
WP7, Windows 8 / Metro
Applications de Création (création de contenu, données, …) avec les applications de style Desktop !
Et de ce fait enclenche doucement une migration en douceur entre les plateformes historiques “Win32 et .NET Fx (y compris SL)” vers HTML ou XAML sur un WinRT…

WinRT qui a ses propres API. Donc si je résume ce que je comprends, dès qu'on utilisera WinRT, on pourra programmer classiquement pour un PC et une tablette (ARM)... mais ce ne sera pas avec la VCL qui deviendra incompatible. Tout cela est à faire vérifier par un spécialiste Windows. Mon interprétation est certainement approximative voire erronée mais je ne lis nulle part un discours clair sur la chose dans le monde "Pascalien".

et en programmant en Java, il faut bien s'appuyer sur des API systèmes.

Pour ce que j'en connais, en Java, "il le faut ?"... mais on évite. C'est le boulot de la JVM de régler les problèmes d'API... ce qui permet de rendre le code portable puisque le code ne "cause" qu'à (n'est interprété que par) la JVM... Le programmeur "métier", normalement, ne touche pas aux APIs parce que son code n'est plus portable... et puis cela semble très compliqué au novice que je suis : je n'en suis pas là ! Dans l'exemple de développements -celui du livre- que je citais, aucune ligne du code métier ne touche aux APIs.

Je regardais récemment comment récupérer le N° de série du disque dur en Java, alors que j'avais été confronté au même problème en Lazarus... En Delphi, il y a une API... Evidemment, en Lazarus, sous Win on peut utiliser l'API mais pas sous Nux...

J'ai fouillé un peu dans les forum. Voici un lien... et une réponse que je trouve représentative :

Premièrement sache que ce genre de méthode ne doit pas être considérée comme 100% fiable, vu que le matériel ça ce change. Je le conseille pas, particulièrement s'il s'agit de limiter l'usage du logiciel.

Pour ce qui est de la détection des identifiants du matériel, ce n'est pas possible directement en JAVA. Il te faudra recourir à du code natif, à suposer que cela soit possible avec du code natif. Il me semble que c'est possible pour le disque dur, par contre ça ne m'étonnerai pas qu'il faille les droits d'admin pour cela. Pour la carte mêre je n'en sais rien.

Le plus facile est sans doute l'adresse mac de la carte réseau. Je ne crois pas qu'il y aie de commande pour l'obtenir directement en java, mais tu peux lancer un Pocessus "ipconfig"(windows) ou "ifconfig"(linux) et lire le résultat.

En Lazarus, j'ai rencontré le même problème. Récupérer le N° de série... pour tout le monde (et surtout quand on n'est pas administrateur)... c'est moins simple que l'API sous Windows.

Bref je ne cherche pas à démontrer la supériorité de Pascal sur autre chose, Java en l'occurrence, ou l'inverse. Je me demande simplement quels efforts me seront nécessaires pour évoluer. Si c'est passer sous FMX, je doute au sens littéral du terme (ie j'hésite). Cela me semble aussi compliqué que de passer à Java et à ses IDE, sachant que dans ce cas, je peux me débarrasser de PHP (pour lequel je ne ressens aucune animosité) et que le développement pour les tablettes m'est offert en prime. Donc la question est, "est-ce qu'a terme, l'environnement Embarcadero ou Lazarus va me permettre de disposer d'autant de capacité de développements ? Et précisément, lesquelles ?"

Cordialement. Gilles

[mick605]

Pour ce que j'en connais, en Java, "il le faut ?"... mais on évite. C'est le boulot de la JVM de régler les problèmes d'API... ce qui permet de rendre le code portable puisque le code ne "cause" qu'à (n'est interprété que par) la JVM... Le programmeur "métier", normalement, ne touche pas aux APIs parce que son code n'est plus portable...

C'est donc "l'équivalent" de la VCL. Il s'agit d'une encapsulation des API pour éviter de les appeler directement. La logique est la même en Pascal ! Si tu prends du code Pascal, tu pourra le compiler sur Linux (avec Lazarus, en faisant abstraction des bugs), et sous Windows (sous Delphi et Lazarus). Le code en lui même sera le même, mais via l'intermédiaire de la VCL (ou LCL), il fera appel aux bonnes API. La grosse différence, c'est qu'il sera nécessaire de recompiler avec la VCL pour le nouvel OS, tandis que la JVM interprète le code.

WinRT qui a ses propres API. Donc si je résume ce que je comprends, dès qu'on utilisera WinRT, on pourra programmer classiquement pour un PC et une tablette (ARM)... mais ce ne sera pas avec la VCL qui deviendra incompatible.

La VCL actuelle ! Tout comme la JVM, on peut penser que la VCL s'adaptera aux nouvelles API.

Donc la question est, "est-ce qu'a terme, l'environnement Embarcadero ou Lazarus va me permettre de disposer d'autant de capacité de développements ? Et précisément, lesquelles ?"

On espère ! Après, il faut voir si les développeurs continuent de programmer en Pascal...

[Invité]

[...] Après, il faut voir si les développeurs continuent de programmer en Pascal...

Ils continueront à développer en Pascal s'ils y trouvent ce dont ils ont besoin. L'affectif compte, mais le pragmatisme est dominant. Franchement, le Pascal est un langage clair, propre très structuré, lisible... Si le nombre de Pascalien a tant diminué alors qu'en plus il était enseigné dans les Ecoles Scientifiques et les Universités et donc à ce titre disposait d'un socle incomparable, à mon avis, c'est à cause d'un problème d'adaptation... que je perçois encore plus "cruel" actuellement.

Je remets un lien d'un article de 2006 -qui m'a valu de me fâcher une fois avec developpez.net- au motif que le lien n'était pas stable. Il existe encore, je l'ai sous les yeux. Une part du contenu de cet article n'est plus adapté à la problématique d'aujourd'hui, mais l'autre pose un vrai problème qu'il ne faut pas éluder.

[...]
La VCL actuelle ! Tout comme la JVM, on peut penser que la VCL s'adaptera aux nouvelles API.

Certes mais quand on constate le retard de la cross-compilation Linux, on peut douter des délais du portage de la VCL en WinRT dans des temps concurrentiels.

Et on en revient au deuxième aspect du problème. Il y a des solutions qui fonctionnent actuellement sous multi-OS (j'ai testé C++/QT et Java et C# avec Mono mais je n'ai pas été convaincu parce que Mono avait une version de retard sur .Net). C'est pas le cas des Pascal (ou mal). On pourra trouver toutes les excuses du monde, justifiées ou non. Mais c'est un fait. Et à mon avis, le problème n'est maintenant plus que multi-OS. Il faut traiter les processeurs usuels notamment ceux des tablettes.


Cordialement. Gilles

[mick605]

Certes mais quand on constate le retard de la cross-compilation Linux, on peut douter des délais du portage de la VCL en WinRT dans des temps concurrentiels.

Et la on est exactement d'accord. Le principal problème, c'est le temps d'adaptation. Mais ce temps d'adaptation est proportionnel au nombre d'utilisateurs, et les utilisateurs quittent le Pascal parce que les outils ne correcpondent pas a ce qu'ils souhaite (a savoir le multiplateforme). C'est un cercle vicieux ...

[skywaukers]

Bonsoir,

Je suis libre d'appartenance à ces diverses catégories de langages. Je lis comme tout le monde, notamment des articles vantant encore la supériorité du compilé sur l'interprété. Et mon analyse, mon expérience, mes tests me démontrent que cette assertion n'est pas une réalité. J'aime la nuance et je me garderai bien de porter jugement sur la valeur de chacun.

Oups, je pense que je me suis mal fait comprendre. Je n'ai pas voulut dire que tu codais mal, je n'ai jamais vu ton code, comment l'affirmer alors ? Ce qui m'a choqué c'est que tu t'appuie sur d'un côté un code non threadé, et qui donc gel lors d'un opération longue, et d'un autre côté une plateforme qui ne gèle pas, parce que probablement elle, elle fait le thread, t'en déchargeant. On en revient donc à ta citation wikipedia, oui les langage interprétés sont plus simples à mettre en œuvre. Mais sur la performance, je ne suis pas d'accord. Ok sur une requette base de données, le temps le plus long va être le dialogue avec la base de données, donc que le client soit compilé ou interprété, ça va pas faire une grande différence. Mais dès que tu as besoin de calculs important, je ne vois pas comment un outils qui va devoir interpréter une instruction à chaque fois avant de l'exécuter sera plus rapide par rapport à un code natif qui sera directement exécuté...

Ceci n'empêche pas que des programmes compilés et écrits par d'autres, j'en vois un grand nombre geler lorsqu'on charge une base (une dbGrid), un document (ftp)... et que j'estime que c'est assez facilement évitable... Enfin pas toujours. Je vante souvent la qualité de synapse à ce sujet comparé à Indy... par exemple qui freeze de manière inexplicable... et incontournable. Alors que vaut l'argument "la plupart du temps moins rapides à l'exécution que les langages compilés en code natif". J'aime bien cette nuance "la plupart du temps".

on est donc d'accord, cela tient de la qualité du développement. Quand au ftp, ok le programme peut ne pas freezer, il faudra quand même attendre que le fichier soit téléchargé pour en disposer, à moins que les langages interprétés fassent dans le miraculeux.
Pareil pour les DBGrid, si elles freezent, c'est que le développeur n'a pas géré la pagination, pourtant simple à faire, et sans même utiliser de thread.

De bonne foi, on peut se contenter de ce qu'on a. Je me suis permis une fois d'intervenir, je crois que c'était sur un forum Delphi qui à l'époque ne compilait qu'en 32 bits alors que les machines 64 bits existaient. L'argument que j'avais lu était de dire que le 32 bits suffisait parce que le 64 bits sous Windows était plus lent que le 32 bits. Là, je crois qu'il est bon -y compris pour un Pascalien convaincu- de regarder ailleurs. Vous ne voyez que Windows et parce que Windows 7 notamment avait des problèmes au départ en 64 bits, son défaut était une justification d'immobilisme et même pire de manque d'intérêt. Alors, pourquoi ne pas être resté au 16 bits et pourquoi pas au 8 bits ?

Delphi est 64 bits quand même !! Regarde dans ton gestionnaire de tâches, tu verras qu'il y a en core tout pleins de programme tournant en 32 bits et je t'assurent ils ne sont pas tous fait en pascal. Après je n'ai pas fait de benchmark entre une appli 32 bits, et une appli 64 bits. De ce que j'ai pu en lire, le gain n'est pas flagrant, voir peut-être même pas toujours meilleurs, les échanges étant forcément plus volumineux. A ce que je pense, le 64 bits est intéressant surtout pour adresser de grosse quantité de mémoire vive, permettant d'avoir ainsi des cache beaucoup plus important et par là donc accélérer les applications.

C'est ce qui m'a séduit sous Lazarus et m'a fait quitté Delphi 7. Une bouffée d'oxygène. Ses développeurs transgressaient et s'ouvraient d'autres horizons.

Ben on peut en dire autant d'Embarcadero quand même, il y a un monde aujourd'hui entre Delphi XE2 et Delphi 7

Ma démarche actuelle et de savoir si une solution multi-OS (enfin c'est un bien grand mot Win, Nux et épisodiquement OS X) me conviendrait mieux que Lazarus.

Delphi XE2 pour le 64 bits et MAcOS, XE3 probablement pour Linux, si tu connais le Pascal et l'apprécie.

FMX, je crois que je vais l'écarter pour l'instant. Cela me fait le même effet que quand j'ai découvert C++/QT. C'est QT qui domine votre écriture. FMX, c'est vgScene où je ne sais quoi d'ailleurs : lorsque je l'ai essayé, je n'ai plus eu l'impression d'écrire en Pascal... enfin celui que je connais et que j'apprécie.

sans jugement de valeur, je ne comprend pas, pour moi on développe en Pascal. Le reproche que je ferai à FMX, c'est sa jeunesse et donc son manque de composants par rapport à la VCL. Mais là c'est un peu comme la doc, c'est aussi aux développeurs de mettre la main à la pâte, comme ça s'est très bien fait à l'époque pour la vcl.

Vous voulez développer Androïd ? XE2 utilise du Lazarus/FPC qui lui même est en retard. Java, cela fonctionne j'allais dire "naturellement".
Vous voulez développez de l'internet ? RadPHP et LazarusForPHP... Hum. IntraWeb... Hum.
Il y a 6 mois, un ami développeur Java m'a mis un vieux livre dans les mains "Les cahiers du programmeur" JAVA EE5- Le support du livre est la réalisation et la gestion d'un site de vente d'animaux. Le site et son back-office sont réalisés en Java. Une vieille version de Java, un portage sous Eclipse puis sous NetBeans, puis sous mySQL... J'en suis resté sur le derrière ! Une solution intégrée (en développement) avec le même IDE en Client Riche et Internet et multi-OS pour le Client Riche. Je pose simplement la question : que propose l'univers Pascalien face à cela ?

Là je pense que tu recherche l'outil parfait dans tous les domaines. Je pense qu'il n'existe pas. Si il existait, je pense qu'il n'y aurait plus d'autres outils d'ailleurs. Je m'étonne qu'il y ait encore un forum Delphi ou C++ si ton ide Java est réèllement si parfait. Je m'étonne encore plus alors de la montée d'objective C, si il existe un aussi merveilleux outil qui permet de faire très simplement la même chose sur IOS...

Voilà le sens de ma démarche. Comme me le dit-affectueusement mon jeune ami javaïen : Gilles tu as 5 ans de retard sur ton choix de plate-forme de développement qui a elle, 10 ans de retard sur ce qui se fait usuellement aujourd'hui. Je médite. Je m'informe. Je soupèse... et je discute.

Je ne pense pas que Delphi ait 10 ans de retard. Au contraire, il va dans la bonne direction à l'heure ou les PC et le browser vont bientôt rejoindre les musés.

@++
Dany

[Invité]

Bonjour,

ce post a été déplacé de sa place d'origine. Au départ, je voulais savoir si Pascal était encore adapté à ma situation et si un avenir se dessinait à terme ce qui nécessitait de ma part d'attendre. Ma décision est prise. Je m'étais donné jusqu'à fin juillet mais le problème était tellement compliqué que j'ai eu du mal à trancher.

Bonsoir,
Oups, je pense que je me suis mal fait comprendre. Je n'ai pas voulut dire que tu codais mal, je n'ai jamais vu ton code, comment l'affirmer alors ?

Il n'y a pas de mal car ce n'est pas ce que j'ai compris. Je n'ai aucune prétention en tout cas pas celle d'être un programmeur hors pair... c'est pourquoi je cherche quelque chose qui s'adapte facilement à mes moyens. Mais si les progrès ont été modestes, j'ai toujours autant envie d'apprendre. Mais apprendre quoi ?

Ce qui m'a choqué c'est que tu t'appuie sur d'un côté un code non threadé, et qui donc gel lors d'un opération longue, et d'un autre côté une plateforme qui ne gèle pas, parce que probablement elle, elle fait le thread, t'en déchargeant. [...]

A la rigueur cela ne me pose pas de problème. C'est assez révélateur de ma recherche.

Je vais prendre l'exemple qui finalement occupe une part significative de mes temps de développements depuis des années. Peut-être percevrez-vous la nuance. J'ai écrit développement et non programmation. C'est la couche métier qui m'intéresse.

Il y a plus de 10 ans, j'ai conçu pour mon lycée un logiciel de gestion de notes : En réalité la première version (monoposte - pas de réseau) a été réalisée en Turbo Pascal et éditait les bulletins sur une imprimante matricielle... Fonctionnel mais limité. La version actuelle a été initialement développée avec Delphi 7, langage qui m'est apparu efficace et direct (et une très belle évolution du TP)... et également une version en Windev 7.5 vraiment fonctionnelle n'en déplaise aux détracteurs de cette plateforme. J'ai d'ailleurs pris autant de plaisir à faire les 2 versions. Mes collègues avaient une nouvelle exigence : celle de pouvoir mettre les notes de chez eux. Tout le monde travaillait en Windows. J'ai dû veiller particulièrement à la transmission des données, prévoir des solutions de secours en cas de rupture de la connexion internet... Une archive était réalisée sous forme d'un zip des bulletins générés en pdf, d'une part sur un de nos serveurs locaux, d'autre part sur un serveur hébergé mutualisé. Lorsque cette opération d'archivage était en cours en fin de trimestre, il était sympathique que parallèlement dans la même session de l'exe, je puisse créer le nouveau trimestre... d'où la découverte puis l'utilisation des threads.

Quelques années plus tard, apparition dans l'établissement et chez mes Collègues d'appareils Linux. J'ai commencé à travailler avec satisfaction avec Kylix puis défaillance de Borland. Plus tard -ce qui veut dire un temps sans solution- découverte de Lazarus 0.9.24. Pas efficace avant Lazarus 0.9.26 et encore. Disons exploitable à partir de la 0.9.28. Le module de saisie des notes a pu être porté sous Nux... pas le reste. (Mais avec les > 0.9.30, donc récemment cela a été possible mais très compliqué. Quelle perte de temps à installer les SVN quotidiennes pour pallier les bugs plus ou moins redondants). Impossible de tenir des délais.

Nouvelle demande d'un Collègue qui ne jure plus que par son Mac. Le module de saisie de notes a donc été récemment porté sous Mac OS X. Mais gros problème avec certains composants... Il a fallu "ramer". J'aurai pu essayer avec XE 2 lorsque je l'ai testé. Mais il fallait revoir toute la "connectique". En effet sous Mac, avec Lazarus, je n'ai jamais pu installer le paquet ZeosDbo. Donc je me suis rabattu sur les connecteurs natifs de Lazarus qui eux ont donné satisfaction. Mais si Zeos existe avec VCL, les connecteurs natifs de Lazarus ne sont pas transposables sous XE2/FMX (et Zeos ?). Bref, je découvrais le produit. J'avais un mois... Je n'ai pas eu le temps de porter mon niveau à ce que requérait FMX pour adapter ou refaire le module. Si j'avais le temps et la volonté, j'essayerais ce portage...

J'allais oublier la demande des parents et des élèves de pouvoir consulter les notes de chez eux. La solution la plus simple semblait de créer une page Web à cet effet. Ce fut fait en PHP. J'ai essayé à l'époque Rad4PHP (solution Code Gear). J'ai passé beaucoup de temps à m'obstiner à créer des "pages pdf" dynamiques au point que finalement, face à la maintenance nécessaire, c'est un logiciel (.exe) qui générait les fichiers pdf tous les jours et les expédier sur le serveur du site. Une autre approche aurait pu être un widget téléchargeable sur le site de l'établissement, compatible Win, Nux et Mac... et installable sur le poste des parents. Mais là, Delphi était et est encore hors jeux actuellement. Je crois que Lazarus pourrait répondre à la question aujourd'hui. Mais il resterait à régler le problème de l'intallation (le déploiement) du programme : Win -> Inno Setup - Nux --> Génération d'un paquet.deb (en général, c'est du Ubuntu) - Mac : je ne sais pas.

Demande récente de mes élèves depuis que nous avons décidé puis réalisé la couverte Wifi complète de notre établissement : et si on avait nos notes sur nos tablettes ? Oups...

Le récit est un peu long. Je sais et j'aurai peut-être pu commencer par l'exemple. Le projet a été initié, il y a plus de 10 ans. Il n'a rien d'extraordinaire... La demande a évolué mais pas ma plate-forme de développement... si Lazarus mais de manière très incomplète et sporadique. S'il y a 10 ans ou après, j'avais retenu Java... j'aurai pu suivre plus ou moins facilement l'évolution des demandes. La différence, c'est que face à la demande, j'avais une solution disponible quasiment immédiatement et pas dans x mois ou années hypothétiquement. De plus, Eclise/Netbeans et Java me propose une plate-forme unifiée... C'est toujours le même IDE.

Alors : oui j'aime le Pascal. Non, il ne s'est pas adapté à la demande et donc à mes besoins. J'estime qu'il n'a pas été bien conduit. C'était un leader, une référence. Et oui, je l'abandonne avec regret.

Cordialement. Gilles

PS : Pour moi, le problème est "tranché". Je remercie tous ceux qui ont exprimé un avis. Cela m'a beaucoup aidé. Je n'écris pas "Résolu", laissant la discussion ouverte.

[M.Dlb]

A l'heure actuelle, si je devais faire du multiplateforme, je me tournerai vers 2 solutions: soit du Java pur en application standalone, soit une application Web avec le couple HTML/PHP.

L'avantage du Java est certain, pour écrire un code une fois qui fonctionne partout (sans évoquer les problèmes de performances, ou de plateformes différentes). La seule raison qui me ferait choisir Java est si l'application doit faire des choses qui ne sont pas faisables dans un navigateur Web: typiquement, édition de données avancée, présentation de données graphiques, calculs... Autrement, mon choix se portera sur une application Web HTML et PHP, qui suffit largement à une application qui fait de l'ajout/modification/suppression de données affichables par un formulaire HTML (quasiment tous les OS sont capables d'afficher une page web !!)

Je n'évoque pas l'option Applet Java, qui est un compromis entre les deux options du dessus....

Il y a cependant une possibilité dont vous ne parlez pas, c'est l'utilisation des CGI-BIN (même si l'apparition des langages comme le PHP leur a filé un coup de vieux). FreePascal et Delphi peuvent générer des binaires utilisables avec le CGI-BIN, donc vous pouvez utiliser le Pascal pour le back-office tout en gardant une couche de présentation HTML...

Offrir des interfaces à tous les utilisateurs de tous les OS, c'est fastidieux quand on a pas l'outil qu'il faut, c'est-à-dire le Pascal Qui a mon sens n'a pas vocation de faire du multiplateforme, tout comme le C ou autre langage compilé du même niveau. Ces langages sont faits pour des utilisations précises, des plateformes particulières. Combien d'applications (commerciales) n'existent que sous Windows (mais leur portage vers Linux est maintenant contraint avec la démocratisation de Linux): modélisation, graphismes, applications scientifiques, médicales, etc....

Votre problème est un problème de développement de l'interface, pas de logique applicative, vous la maitrisez totalement en Pascal. Changez de méthode de développement d'interface

(Oui je sais, facile à dire hihihi)

[skywaukers]

Bonsoir,

ok, l'important est que tu ais résolu ton problème. Cependant à mon avis Delphi XE2 couvre la majorité de tes besoins, je dirai excepté Linux, puisque tu peux développer pour windows (32 et 64 bits), pour MacOS, pour IOS (IPhone/IPad) via une compilation sous Lazarus, mais un développement sous l'IDE de Delphi. Pour le reste tu peux le faire avec Intraweb. Il est même très simple de faire un serveur web pour mettre à disposition une application de consultation de bulletins de notes. D'ailleurs le principal défaut d'Intraweb est de ne pas pouvoir être porté sous linux, ce qui augmente le coup de l'hébergement, ou oblige à héberger soit même.
Bon, après c'est sur le jardin du voisin est toujours plus facile à entretenir que le sien , je comprend qu'on soit tenté par une autre aventure aussi

@++
Dany

[Invité]

Bonjour,

J'ai lu avec intérêt vos remarques. Je trouve, comment dire, "inapproprié", le "il est très simple de". J'aime bien contester -un vieux conditionnement universitaire sans doute- et j'adore les débats.

Donc j'ai le plaisir de contester. Sans prétendre avoir raison, mais avec conviction :

Bon, après c'est sur le jardin du voisin est toujours plus facile à entretenir que le sien , je comprend qu'on soit tenté par une autre aventure aussi

Cela pourrait être le cas. Mais tel n'est pas. Mon langage, c'est le Pascal. Mon IDE c'est Delphi7/Lazarus -des frères siamois- mais pas Delphi 2005, 2007. Alors Netbeans et Eclipse encore plus "lourds" ? Et bien, je les trouve sympas ! Certes cela semble contradictoire... je pourrais peut-être le justifier... un autre jour ? Mon problème est le résultat d'une contrainte sans véritable solution actuellement : Produire dans un temps limité sans que cela devienne une galère... Même si ce n'est pas mon métier. Ma réalité est que l'objectif est pénible à atteindre avec Lazarus, jamais impossible, mais parfois (voire souvent ) intensément pénible.

[...] Pour le reste tu peux le faire avec Intraweb. Il est même très simple de faire un serveur web pour mettre à disposition une application de consultation de bulletins de notes. D'ailleurs le principal défaut d'Intraweb est de ne pas pouvoir être porté sous linux, ce qui augmente le coup de l'hébergement, ou oblige à héberger soit même.

Il n'est pas très simple d'héberger "à domicile" son propre serveur internet. Une connexion ADSL est inadaptée et une connexion adaptée dans notre pays coûte encore une fortune, quand on peut en disposer malgré toute la flagornerie diligentée institutionnellement. La configuration correcte du serveur n'est pas aisée. Sa protection et le travail continu qu'elle nécessite, encore moins. De très, très loin, la meilleure solution actuellement pour une petite équipe qui ne dispose pas à plein temps d'un admin'sys est l'hébergement mutualisé ou l'hébergement d'un serveur dédié à condition que l'hébergeur assure ce travail de maintenance et de protection.

Il y a cependant une possibilité dont vous ne parlez pas, c'est l'utilisation des CGI-BIN (même si l'apparition des langages comme le PHP leur a filé un coup de vieux). FreePascal et Delphi peuvent générer des binaires utilisables avec le CGI-BIN, donc vous pouvez utiliser le Pascal pour le back-office tout en gardant une couche de présentation HTML...

Je n'en suis absolument pas convaincu. Pour avoir testé le CGI-BIN, le fait d'utiliser un exécutable permet effectivement des traitements au lieu de passer par d'autres librairies PHP par exemple mais, à mon avis, on ne code pas un site majoritairement avec des CGI-BIN mais uniquement pour répondre à des besoins spécifiques et/ou ponctuels.

Le "Changez de méthode de développement d'interface" m'interpelle beaucoup. J'ai loupé quelque chose ? Chouette ! Il existe une solution en Pascal que je n'ai pas envisagée. Mais quoi exactement ?

Je reprends les termes précis :

Votre problème est un problème de développement de l'interface, pas de logique applicative, vous la maitrisez totalement en Pascal. Changez de méthode de développement d'interface

J'ai du mal à comprendre, à placer votre proposition dans ma logique. Et, je pense que vous avez le même problème en Delphi, maintenant (ie à partir de maintenant). Pour résoudre le problème ci-dessous que j'ai rencontré -c'est un souvenir cuisant-, quelle interface utiliser ?

Je lisais, intéressé, une discussion sur l'impossibilité de générer du pdf actuellement sous FMX. Je me permets -et c'est rare- d'exprimer mon ressentiment à l'égard non pas de Delphi mais de ses propriétaires : Si le problème était Lazarusien [ mais dans ce cas précis, "on" sait le faire], je dirais "cela va venir" et je ferais connaître mon irritation dans le bug tracker en conversation privée. Il a un rapport induit par le fait que les lazarusiens sont une communauté "libre", open-source et non lucrative. Ce qui m'incite à ne pas avoir le même avis tranché que pour Delphi. Mais j'en conviens, et c'est pourquoi je cherche une autre solution : à l'arrivée, les conséquences sont identiques et sont caractérisées, non par une incapacité, mais par un ralentissement très, très important.

Quand il s'agit de FMX intégrée au Rad Delphi, ex-propriété de la société Borland, ex-propriété de la société Code Gear, propriété de l''actuelle société Embarcadero, toutes à but lucratif, ayant ce qui s'appelle des clients, je renonce à choisir Delphi. Ce n'est pas qu'un problème technique. C'est un problème au minimum commercial de rapport entre les "repreneurs" et les utilisateurs. Je voyais qu'Arkhamon s'attelait à la tâche du pdf. Et Paul expliquait que c'était plutôt jouable (réf à PDFLIB), alors que Shaï et Arkhamon était en train de se battre avec des problèmes d'échelle. Jouable ? On ne joue pas dans la même cour. J'ai essayé pdfLib pour afficher mes bulletins de notes sur le site. Sur la TForm, les Cells de ma TStringGrid (contenant les avis des enseignants) ont "appris", figées en largeur, à auto-gérer leur hauteur. Quand il a fallu transférer ceci en pdfLib sous PHP, sans compter évidemment que le fait que toute la ligne (intitulé de la matière, moyennes,...) doit prendre la hauteur de la "cellule" contenant l'avis, le tout (il n'y a pas qu'une matière) pouvant dépasser une page avec des blocs insécables, malgré tout le temps passé, je n'ai pas trouvé cela très jouable. On est sensé y passer combien de mois ?

Un bon générateur de reports avec une possibilité de générer du pdf... pas disponible non plus sous FMX... facilite "un peu" le travail. Ca, oui c'est changer d'interface ! Le générateur crée chaque bulletin en pdf et l'expédie par ftp dans le répertoire du site. Cela fonctionne. J'ai pratiqué ainsi. On fait cela une fois par jour éventuellement par un service ou un cron.

Je me suis beaucoup interrogé sur l'avenir de Delphi parce qu'il représentait 50% d'une solution Pascal (l'autre possibilité étant Lazarus) : il faut savoir si les "Repreneurs" perdurent dans leur attitude de "rentiers" -capitalisant sur le vieux Win32 en fin de vie et ce qui reste de la communauté Delphi- ou si, sous la contrainte pour perdurer un peu, il bricole un ersatz de multi-plateformes avec un marketing, il faut reconnaître, qui m'a "troublé"... ou s'ils acceptent de traiter toutes les plateformes équitablement...

L'émotion, la passion n'étouffent pas la raison. Les 2 ans de jeunesse sont un argument que je n'entends pas : cela fait 10 ans que Java et Lazarus sont multiplateformes et d'écrire que Delphi n'a pas 10 ans de retard en multiOS, c'est peut-être oublier trop facilement l'existence de Kylix et sa date de naissance !

Donc, je comprends votre argumentation mais Delphi n'est plus ce que vous croyez -en tout cas n'est plus présenté comme tel- sauf pour les windowsiens... qui semblent former -et pour cause- la très grande majorité des utilisateurs. Combien des utilisateurs de Delphi utilisent autant Linux que Windows ? C'est mon cas... Et voila pourquoi choisir Delphi serait déjà une énorme concession : je ne peux pas programmer sous "ma" Debian. Alors d'autres concessions, je n'accepte pas.

C'est simple. Ma position pour Delphi est la suivante : "Vous prétendez me permettre avec votre produit de réaliser des développements multi-plateformes. Prouvez-moi déjà qu'il le permet en portant votre IDE sous Nux et Mac OS". Le vieux Delphi 7 est bien écrit avec votre Pascal ? Faites-en autant avec XE3 et je serai un Client !" L'IDE Eclipse Platform est principalement écrit en Java. Netbeans aussi. Il serait à mon avis souhaitable que le Delphi multiOS le soit aussi (pas en Java mais en FMX si c'est la solution retenue par Embarcadero). Ce serait un gage de qualité et il serait complet. De toute façon, je suis très réservé -c'est le moins que je puisse dire- par la cross-compilation. Avec Lazarus on dispose de la cross-compilation. Mais rien de tel pour mettre au point le programme que l'IDE dans chacun des OS.

Enfin, si je peux me permettre -mais comme je suis sur le forum Pascal et non Delphi, je le fais- : l'équipe Lazarusienne -quelque soit sa valeur et, à mon avis, aucune suspicion n'est à formuler à ce sujet- est ancienne et il me semble que cela la sclérose comme n'importe quel groupe dont le noyau est restreint et les apports non renouvelés. Pourtant, ils ont gardé ou capté l'esprit Borland. En tout cas, c'est comme cela que j'avais perçu le contact avec Borland qui n'était pas que commercial à l'époque. Un projet de 10 ans, c'est long. S'il y avait du sang neuf, notamment, des programmeurs comme ceux qui interviennent en Delphi sur ce forum, je crois que Lazarus deviendrait LA solution. En multiplateforme, ils sont en avance sur tout... Des connecteurs, à l'interface, aux éditeurs, sur de nombreux composants. Il n'ont qu'une seule LCL, un Pascal que j'estime robuste (je n'ai jamais eu un problème avec). Il n'y a rien que je ne puisse faire en Lazarus que je faisais en Delphi 7 aussi bien sous Win que Nux. Mais mes besoins ont "augmenté" depuis Delphi 7. Simplement l'ensemble est instable (mais pas inutilisable). Certains "pans" ne sont pas mis à jour (la transmission des savoirs est "aléatoire" et/ou sans suite -voir TDbf que j'ai testé cette semaine). Le développement est également trop dispersé compte tenu du nombre limité de programmeurs.

Pour en revenir, à mon choix, j'ai déjà vu en 6 mois d'utilisation de Java, plein de choses "irritantes". Ils sont irritantes par rapport à ma pratique (par comparaison) mais pas techniquement (Ah les connecteurs Pascal ). Et cela fonctionne : on se coule dans le moule et cela fonctionne. Mais c'est vrai que pour un Lazarusien, c'est extrêmement contraignant. Je teste pendant 6 mois. Et je ferai le bilan sans hésitation. Là, je n'ai pas d'affinité au départ avec le Java.

Je continuerai de toute façon à développer en Pascal de manière beaucoup moins intensive évidemment, histoire de me rappeler un autre usage des {}... mais plus en production avec des calendriers à tenir. J'espère que Delphi évoluera dans le bon sens (le mien). Mais franchement si Lazarus peut régler ses problèmes...

A bientôt- Cordialement. Gilles

[M.Dlb]

Je n'en suis absolument pas convaincu. Pour avoir testé le CGI-BIN, le fait d'utiliser un exécutable permet effectivement des traitements au lieu de passer par d'autres librairies PHP par exemple mais, à mon avis, on ne code pas un site majoritairement avec des CGI-BIN mais uniquement pour répondre à des besoins spécifiques et/ou ponctuels.

Oui, lesquels ? Peut-être les vôtres ?

Pour moi le CGI-BIN, c'est exactement la même chose que le PHP, le JSP ou l'ASP, c'est-à-dire un code qui tourne sur le serveur, récupère des données du client (formulaire HTML) et les traite. On peut créer des sites entièrement en CGI-BIN, rapellez vous au début du web dans les années 95-96 quand il n'y avait que cette possibilité Certes les sites n'étaient pas aussi développés qu'aujourd'hui - bien que de nos jours le contenu dynamique fasse le bonheur des développeurs "Web" - mais il est à mon avis tout à fait possible de faire un site Web en CGI-BIN.

Le "Changez de méthode de développement d'interface" m'interpelle beaucoup. Et me revoilà, sur votre forum. J'ai loupé quelque chose ? Chouette ! Mais quoi exactement ?

Je reprends les termes précis :


J'ai du mal à comprendre, à placer votre proposition dans ma logique. Et, je pense que vous avez le même problème en Delphi, maintenant (ie à partir de maintenant).

Je me référais à votre problème que vous avez décris plus haut. D'après ce que j'ai compris, du moins pour l'application de saisie de notes, le problème vient du fait que l'application s'ouvre à de nouvelles plateformes, mais dans votre développement, la couche de présentation de données (l'interface) est intimement liée à la couche "métier", ce qui était certainement un choix judicieux aux débuts du projet mais qui est aujourd'hui une contrainte.

Ma réflexion était donc de séparer ces deux couches, garder la couche "métier" (gestion des notes, connexion à la DB, droits utilisateurs, etc...) en Pascal (par exemple en CGI-BIN ou autre serveur standalone), et fournir une couche de présentation (formulaires d'ajout/modification/suppression, etc) dans un ou plusieurs autres langages (Java, HTML, ...).

Votre projet a atteint une taille non négligeable, et votre modèle logiciel ne vous permet plus de fournir des clients lourds pour toutes les plateformes, ce qui vous demande énormément de temps. Ce n'est que mon avis, mais il me semble que vous devrez à un moment donné, tôt ou tard, modifier la structure de vos programmes, pour vous éviter de maintenir x versions parallèles.

[skywaukers]

Bonjour,

pourquoi les gens qui veulent partir du monde Pascalien se croient obligés de mener une inquisition et vouloir dégouter les autres, se croyant d'un coup illuminés de la vérité absolue. Certes Java (que je ne critique pas techniquement) possède ses gourous de la pensée unique, et c'est moi ce qui m'a toujours déplus dans cet univers.
Reprocher à Embarcadero d'être une entreprise à but lucratif, bon ok (vous avez un bulletin de paye je pense à la fin du mois ? Vous avez besoin de gagner de l'argent pour remplir votre frigo ? Les autres aussi, enfin c'est un autre débat). Mais revenons à l'aspect technique, vous dites que Lazarus a une LCL unique et pas Delphi. Mais FMX est exactement cela, il n'est pas dédié qu'aux plateformes non win32. Oubliez la vcl plutôt.
Et oui, FMX n'a que 2 ans, et non Delphi XE2 n'a pas 10 ans de retard (Delphi 7 oui, c'est vrai). Au passage, concernant le PDF, il me semble que même si Embarcadero est une société gangrénée par la soif de l'argent comme vous le laissez entendre, et bien ce problème va être résolut le mois prochain.
Maintenant sur l'IDE, oui ce serait bien un IDE non cantoné à windows. Mais si il l'est ce n'est pas la faute à Embarcadero, mais à Borland, qui dans sa logique floue des dernières années s'est emmêlé dans l'écriture d'un IDE mélangeant code natif et code .NET (tiens une critique que vous avez oublié il me semble, je vous la souffle donc : pour travailler avec Delphi et écrire du code natif win32, il faut installer le framework .NET). Alors Embarcadero pourrait re-écrire un IDE tout neuf, mais est-ce si important ? Est-ce là qu'il doivent mettre leurs efforts ? C'est vrai que Borland avait fait cet effort avec Kylix, mais ils ont été récompensé comment leurs effort ? Combien de licences Kylix ont été vendues ? Je suis sûr qu'il n'ont même pas amorti le coût de son développement. Intellectuellement c'est bien, oui. Mais les contraintes économiques sont là aussi. Embarcadero paye ses développeurs lui, il ne profite pas sans scrupule du travail de bénévoles de très bonne qualité comme l'a fait Sun durant des années.
Je ne pense pas non plus qu'ils jouent les rentiés avec win32, il se trouve seulement que des gens ont encore besoin de win32, il se trouve que la population de développeurs Pascal est aujourd'hui encore majoritairement sous windows, c'est donc vital pour eux de continuer à les satisfaire, tout en leur ouvrant de nouvelles voies, ce qu'ils font. Et je maintient, et signe que même si ils ne vont pas dans votre sens (finalement vous avez surtout besoin d'avoir une application web, ce qu'on peut faire avec Delphi depuis plus de 10 ans, et qu'on peut faire très simplement avec Intraweb en respectant les délais, je viens de terminer un configurateur produit pour un groupe industriel, livré mi-juillet alors que le délais était au 10 septembre. Et sans vouloir faire le fanfaron, il me semble que le sujet est un peu plus complexe qu'une interrogation de bulletins de note). Bref, ils vont aujourd'hui dans le sens des applications mobiles (IOS et Android le mois prochain si je ne me trompe pas), c'est la bonne direction. Encore une fois, votre bon vieux PC sous windows ou Linux est en fin de vie, les jeunes n'aiment plus surfer derrière un écran d'ordinateur, c'est la techno de papa ça. Aujourd'hui, et de plus en plus demain, l'outil sera la tablette et/ou le téléphone. Moi même chez moi je passe beaucoup moins de temps sur mon PC pour autre chose que le travail depuis que j'ai un smartphone et une tablette.
N'étant pas adepte personnellement de la pensée unique, je vous souhaite une pleine réussite dans vos futurs projets Java, mais cela est votre choix.

@++
Dany