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)

[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

[marly2010]

bonjour,

Les retards d'Embarcadero sont en effet regrettables MAIS.

1) il est cohérent de privilégier les plateformes serveurs et clients tels que Windows et MAC OSX.
Pour Linux, Embarcadero pourrait maintenir une solution minimale : en attendant, elle existe sous la forme Lazarus / FreePascal ou encore en C (présent dans RAD STUDIO). Et puis, pour Linux, quel est le marché ?

2) pour les plateformes mobiles, ios comme android gagnent à être servi par la même plateforme avec un IDE le plus proche possible de DELPHI XE (N).
La précédente solution pour ios, trop différente de mac osx, trop difficile ou délicate et n'intégrant aucune solution ANDROID n'était pas viable.
Le développement serveur avec Data Snap et autres techno serveurs et les solutions HTML5 Builder (dont PHP serveur et HTML/javascript client) et la future plateforme mobile studio sont elles de bonnes solutions (en perspective pour la solution mobile...).

Les avancées de la nouvelle platforme sont :
- performances pour FIREMONKEY - FMX ainsi qu'extensions vers WIN 8
- consolidation pour Livebinding
- HTML5 (ex-RAD PHP)
- mobile studio : à condition de tenir la date de début 2013... car sinon ce sera un coche de plus de raté...

pour DELPHI et C++, il n'y a pas d'avancées fondamentales (hormis via FMX et LiveB.) comme c'est normal pour toutes les solutions mures (les bases de données ne changent pas grand chose au support SQL par exemple).

3) pour répondre sur le multiplateforme : il ne faut pas une solution "faute de mieux" qui soit beaucoup moins performante et pratique que la solution native. Il est clair que pour une appli ANDROID classique (sans composant spécifique), il faut faciliter le développement HTML5/JS/JAVA plutôt que s'évertuer à faire du Pascal 100%.

4) pour l'aide en ligne, je ne comprends pas en quoi Eclipse est bon. Si la solution DELPHI XE3 est contestable, au moins donne t elle un accès très complet non seulement à l'aide mais à des exemples de codes y compris sous internet (Embarcadero et autres sites)... donc je vote pour, tout en reconnaissant que dans DELPHI 7 avec WINHLP s'était un peu plus pratique pour l'aide intégrée immédiate (mais pas pour chercher des solutions).

Cordialement
François