IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Lazarus Pascal Discussion :

Lazarus, où en est-on ?


Sujet :

Lazarus Pascal

  1. #1
    Invité
    Invité(e)
    Par défaut Lazarus, où en est-on ?
    Bonjour,

    j'ai dû quitter Lazarus il y a plus d'un an pour résoudre des problèmes insurmontables avec cet environnement de développement, principalement la gestion du texte enrichi. Après une période de recherche très longue et de nombreuses interrogations, mon choix s'est porté finalement sur Qt 4 d'abord puis rapidement 5. Mais régulièrement, je fais le point que je rends public.

    Je réinstalle périodiquement Lazarus sous Windows et parfois sous Linux pour réaménager un vieux projet que je n'ai pas le temps de porter en Qt. La dernière tentative était cette semaine: un ancien projet développé avec ZeosDbo 6. Évidemment, comme assez souvent, l'installation du composant n'a pas fonctionné du premier coup, a nécessité la visite de forums et le téléchargement d'un correctif... qui a le mérite de fonctionner proprement.

    Et comme d'habitude, j'ai éprouvé un immense plaisir à écrire du Pascal, de pouvoir factoriser du code, à utiliser un système d'ancrage intelligent et efficace sur mes objets graphiques.

    Maintenant, j'ai un peu de recul entre Lazarus et Qt.

    Je parle peu de Delphi... enfin de son "successeur" car, pour moi VCL est moribond à court terme. et FireMonkey n'est pas Delphi. Je perçois FireMonkey comme la convergence de tout ce qu'il y a de mauvais dans Lazarus et Qt ! De Lazarus, la pauvreté des composants et de Qt, l'usage d'un code lié aux objets graphiques qui défigurent et dénaturent le Pascal, une imbécile complexité inutile* (les styles, les Binding, …). Il ne manque plus qu'à imposer l'utilisation des pointeurs à tous les coins de code, et la «mutation» sera totale. J'oubliais une autre particularité : l'obligation d'utiliser la cross-compilation (sous mac OS)... Enfin , je n'ai pas étudié XE6 mais mon ressentiment car c'en est un, est que FireMonkey de part sa volonté de combiner programmation pour tablette, phone et mac OS par exemple, nous propose un mixte inadapté pour du client riche.
    *Je parle de celle de FMX

    Qt
    • C'est du lourd, du riche à tous les sens du terme.

    • C'est réellement multiplate-forme. Son éditeur, comme celui de Lazarus, fonctionne sous Win, Nux 32 et 64 et mac OS X. Le «comme Lazarus» est un peu usurpé. Avec Lazarus, sur mon mac, il faut faire des tonnes de concessions notamment sur la couche graphique. Lazarus est en déshérence sous mac OS. Il y a presque 2 ans, j'avais acheté un mac que j'ai revendu rapidement puisque, déjà à l'époque, je m'étais rendu compte que le développement avec Lazarus était une illusion. J'en ai racheté un pendant les vacances. Avec Qt, impeccable!

    • C'est la possibilité d'utiliser toutes les bibliothèques et classes C++.

    • C'est un code moyennement lisible pour un Pascalien, un code bavard: on trimbale du
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    monObjet->methode1();
    monObjet->methode2();
    monObjet->methode3();
    au lieu de
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    with monObjet do begin
    	methode1();
    	methode2();
    	methode3();
    end;
    Si monObjet est ui->moncomposantgraphique, cela devient rapidement «long». Evidemment sur 3 lignes, ce n'est pas évident du tout. Et même on pourrait croire à un contre-exemple. C'est le principe d'écriture qui est avantageux : en imaginant des objets et des codes imbriqués (par exemple des Rect dans des objets graphiques), la différence apparaît rapidement et nettement au profit du Pascal.

    • C'est également des bugs : les QWebview sont partiellement bugués. C'est également une perte de compatibilité entre release. Entre la 4 et la 5, la classe traitant les fonctions ftp a été totalement remaniée. Mais elles ne sont pas équivalentes: avec la nouvelle, il n'est pas possible de lister simplement un répertoire distant. La plupart des développeurs utilise alors «la vieille» remise au goût du jour mais déclarée obsolète.
    • Ceci dit l'évolution a un prix. Donc ce n'est pas comparable à Lazarus qui est à la traîne et qui est largement, très largement bugué. Différence de moyens évidemment mais pas seulement.

    • C'est une licence commerciale, qui si on veut diffuser ses programmes sans en donner le source (je n'imagine pas donner les codes d'accès de mes bases, de mes serveurs ftp...) oblige une compilation dynamique du programme et une diffusion de ce dernier accompagnée d'une ribambelle de bibliothèques dont on ne voit pas toujours le rapport avec l'équivalent des uses (les includes) du projet.. Bibliothèques qu'il faut identifier sous tous les OS... Le prix de la licence commerciale : environ 300€ mensuels. Une fois acquise, on peut utiliser la compilation statique sans diffuser les sources.

    • C'est un ide compilé (Qt Creator) en VS2010-x86 quelque soit la version Windows du SDK 32/64 bits avec MinGW (uniquement en 32) ou VS20XX. Oui, l'éditeur n'est diffusé qu'en une seule version sous Windows.

    • Qt, c'est la prise de tête pour intégrer des composants personnels, prise de tête notamment liée à la compilation choisie. J'ai passé 2 mois à résoudre ce problème. «Ils» ont une solution de rechange liée au projet et non pas à l'IDE donc mal portable d'un projet à l'autre et d'aucun usage dans l'éditeur. Quand on vient de Delphi/Lazarus, cette approche est limitée et vraiment largement inférieure.

    • C'est une documentation floue, à mon avis suffisante pour appâter le Client (en faire un futur Client), mais insuffisante pour rendre réellement autonome un «Indépendant». Il m'a fallu plus d'un mois de tâtonnements pour recompiler le SDK en minGWw-64. Les informations sont dépassées, les options de compilation «obscures»... à mon avis volontairement. Finalement, je relativiserais la faiblesse de celle de Lazarus.

    • Qt, c'est également la préférence du HTML comme RichText (et pas RTF) dans l'équivalent des lzRichEdit et des Grids. Je ne m'en étais pas rendu compte avec Lazarus, mais c'est un choix évident et judicieux.

    Au final, Qt est un environnement qui m'a toujours permis d'atteindre jusqu'à présent mes objectifs multiplate-formes même si je ressens souvent une approche moins productive que Lazarus et une impression de bridage volontaire, non pas d'un bridage technique, mais d'une volonté de ne pas faciliter le développement en licence libre.
    ---
    Avant de passer à Lazarus, le pont entre les 2 environnements... Je n'ai pas pu compiler Lazarus avec Qt en utilisant Qt 5. Sur la page web du binding Qt proposée par Lazarus, une version serait en développement. En lisant le forum anglais, pas avant un an. Compte tenu des différences des vitesses relatives des 2 mondes, il faudra se limiter longtemps à Qt 4.8, à mon avis. Et ce n'est pas grave !

    J'ai réussi à utiliser Lazarus-Qt avec Qt 4.8 compilé en MinGW 4.8.2. Inutile d'essayer avec une Qt 4.8 compilée en VS 2008 ou VS 2010 car Lazarus ne comprend pas les bibliothèques produites par les compilateurs qui leur sont associés. Je n'ai pas essayé en Win 64. Il aurait fallu recompiler Qt 4.8 et pendant la moitié des vacances, un appareil dédié à la compilation fonctionnait en quasi permanence pour les tentatives de compilation de Qt 5.3 en minGW-w64...

    Bref, avec une Qt4Pas5.dll compatible -pas celle du site Lazarus binding-, cela fonctionne. Enfin, c'est beaucoup dire. Le mélange des 2 mondes est totalement indigeste et la régression pour un développeur des «possibilités» de Lazarus est importante et à mon avis inacceptable. Le prix à payer est trop important dans le confort d'utilisation, dans les contorsions imposées. Et puis quand on connaît les capacités de Qt même modestement, on se sent immédiatement brimé avec Lazarus-Qt. Au terme de mon essai, je considère que Lazarus-Qt est un palliatif malhabile et fortement contraignant aux insuffisances de Lazarus et plus précisément de ses wrappers vers les objets graphiques "natifs" des OS.
    ---
    Lazarus
    • Mon cher Lazarus est un langage génial, une approche très pertinente et astucieuse, celle de Borland, meilleure que FMX qui en réalité est l'achat d'un add-on plus ou moins bien intégré. C'est donc évidemment un autre niveau d'ambition, et une productivité impressionnante... mais sans issues de secours.

    • Lazarus, c'est une équipe de développement pointue, limitée en nombre, à mon avis plus ou moins volontairement, par une pratique de captation et d'intégration inadaptée. Lazarus, c'est un copiage aussi : celui de Delphi 7. Cela a amené des ressources mais aussi des contraintes et de très mauvaises habitudes.

    • Lazarus, c'est un fonctionnement que je pourrais presque comparer à une approche sectaire, toute proportion gardée évidemment. Plus ou moins refermé sur lui-même et isolé, pas toujours orienté vers les utilisateurs mais parfois vers la satisfaction de son équipe de développement. Son forum m'effare. La critique souvent justifiée y est systématiquement rejetée, mise à l'écart. J'ai lu récemment un article sur fpGui, développée par un membre fondateur mais qui n'est pas la voie officielle: qualifié de «spam». Et donc ce comportement induit directement ou non, un manque de développeurs. Déjà Delphi était une niche...

    • Ce qui n'arrange rien. Lazarus présente un turnover important de développeurs et d'utilisateurs. Combien de composants tiers ont perdu leurs initiateurs? Lazarus, c'est l'amour puis la haine. Un projet qui ne rend pas indifférent, mais qui comme Delphi, pour des raisons différentes, repoussent à terme ses utilisateurs.


    Lazarus, pour moi, restera pourtant digne d'un projet universitaire. C'est élogieux d'une part. Mais à contrario, ce curieux management, ce manque de vision -peut-être expliquée par la faiblesse de l'effectif- et donc une approche défensive, cette perte de l'objectif de développer pour des utilisateurs, a également des conséquences : à la vitesse où les OS se développent et évoluent, une politique déclarée ou subie par des pratiques inadaptées est nécessairement stagnante voire régressive. Si la vision de ses initiateurs était aussi éclairée et ouverte que le code qu'ils développent...

    Cordialement. Gilles
    Dernière modification par Roland Chastain ; 06/09/2014 à 21h12. Motif: ajout préfixe

  2. #2
    Modérateur
    Avatar de tourlourou
    Homme Profil pro
    Biologiste ; Progr(amateur)
    Inscrit en
    Mars 2005
    Messages
    3 854
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 61
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Biologiste ; Progr(amateur)

    Informations forums :
    Inscription : Mars 2005
    Messages : 3 854
    Points : 11 287
    Points
    11 287
    Billets dans le blog
    6
    Par défaut
    Bonjour Gilles,

    Merci de partager votre expérience.

    Si j'ai bien compris les dernières nouvelles de CodeTyphon, le développement évolue vers la possibilité d'un ensemble de composants graphiques multi-plateformes basés sur OpenGL. Une sorte de Qt ? Mais pour un dérivé de Lazarus.
    Delphi 5 Pro - Delphi 11.3 Alexandria Community Edition - CodeTyphon 6.90 sous Windows 10 ; CT 6.40 sous Ubuntu 18.04 (VM)
    . Ignorer la FAQ Delphi et les Cours et Tutoriels Delphi nuit gravement à notre code !

  3. #3
    Invité
    Invité(e)
    Par défaut
    Bonjour Yves,

    Si vous parlez de fpGUI, il est très loin d'être finalisé. Et surtout il n'est pas intégré à Lazarus malgré la présence dans les Types de composants graphiques LCL de "fpGUI (alpha)"... qui ne permet pas la reconstruction de Lazarus dans ce mode. Donc, de ce fait, il est impossible d'utiliser les objets de la palette de l'IDE. Il en existe un autre d'ailleurs directement interfaçable avec FPC (un concurrent de Lazarus en quelque sorte). Et c'est sans doute pour cela qu'il y a quelques tiraillements sur le forum anglo-saxon de Lazarus. Je vous recommande la lecture édifiante du dernier post sur la question (22 août) auquel je faisais référence dans le premier message.

    D'un autre côté, je ne sais pas si les programmeurs de Typhon qui est surtout un installateur très bien réalisé d'une panoplie de composants Lazarus ont les compétences pour créer les wrappers indispensables au pilotage des widgets natifs des OS parce que c'est là qu'actuellement réside le principal problème, à mon sens. Sur mac OS, ce n'est plus un problème mais une vraie menace : "ils" doivent prier qu'à chaque nouvelle mouture de mac OS X, Carbon soit encore supporté. Car dans le cas contaire, il n'y a plus d'environnement graphique sauf à utiliser Lazarus-Qt. Les widgets natifs existent dans les différents OS. Encore faut-il les piloter. Alors choisir l'option d'utiliser une surcouche ou une couche de remplacement, un peu à la FMX, c'est à mon avis contre la nature de ce qui fait l'essence même de la LCL. Et c'est aussi mon ressenti sur Typhon. Quelle est sa véritable utilité ? Mais ce n'est qu'une opinion.

    Si vous ne parlez pas de fpGUI -parce que il ne me semble pas que fpGUI repose sur OpenGL ou alors je ne m'en suis pas rendu compte et il s'est installé à "l'insu de mon plein gré", auquel cas c'est curieux, j'ai travaillé un peu avec celui-ci ... mais pas en Lazarus.

    Actuellement, franchement, je ne perçois pas le "blocage" comme principalement technique mais... autrement : Pourquoi les lzRichEdit, Richmemo et autres grids affichant du texte enrichi sont dans un tel état de dénuement (ie incomplets) pour les premiers ou inexistantes pour les secondes ? Principalement à mon avis parce que les développeurs du Team Lazarus, qui utilisent ce produit à des fins personnelles -ce qui ne pose pas de problème en soit-, n'en ont pas directement besoin... Que le développement d'une telle Grid serait gourmand en temps -compte tenu du code actuel des CustomGrids- et pas "amortissable". Donc la présence de ce type de composants dans la palette n'est pas "jugée" utile. Mais c'est une énorme infériorité par rapport à d'autres plateformes multi-OS. J'insiste sur les textes enrichis mais on peut de la même façon trouver une quantité de composants mal finis, mal portés, mal maintenus. Et c'est donc le pilotage que je conteste. Quid des utilisateurs réguliers de Lazarus ?

    Le discours officiel est lisse. Mais les faits sont tenaces... et en décalage. N'y lisez pas un quelconque ressentiment. Ma page Lazarus est actuellement tournée même si régulièrement je teste, j'essaie de rester informé. Rien n'est définitif.

    Cordialement. Gilles
    Dernière modification par Invité ; 06/09/2014 à 16h23.

Discussions similaires

  1. [Lazarus] Lazarus est-il adapté au développement professionnel ?
    Par Alcatîz dans le forum Lazarus
    Réponses: 22
    Dernier message: 31/08/2014, 13h12
  2. [Lazarus] Lazarus 1.0 est disponible en version Release Candidate
    Par Alcatîz dans le forum Lazarus
    Réponses: 7
    Dernier message: 29/08/2012, 21h01
  3. [Lazarus] Delphi attaqué par un virus : Lazarus est-il menacé ?
    Par jojpa54 dans le forum Lazarus
    Réponses: 1
    Dernier message: 24/08/2009, 18h34
  4. Réponses: 3
    Dernier message: 27/05/2007, 15h40
  5. [Lazarus] Où est le Help
    Par Cazaux-Moutou-Philippe dans le forum Lazarus
    Réponses: 1
    Dernier message: 23/06/2006, 23h41

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo