Pourquoi utiliser Pascal

 (castle-engine.io)
2 points par GN⁺ 2023-07-10 | 3 commentaires | Partager sur WhatsApp
  • Object Pascal vise à conjuguer un langage orienté objet moderne et lisible avec des performances natives, et constitue une option pour créer des applications maintenables sur plusieurs plateformes
  • Grâce à un typage fort, à des vérifications à la compilation et à l’exécution, il est plus facile de filtrer des erreurs comme les fautes de frappe dans les noms ou les incompatibilités de type avant qu’elles n’atteignent l’utilisateur
  • Si nécessaire, il est possible d’utiliser des pointeurs, du code spécifique à l’OS ou au CPU, voire de l’assembleur, mais Castle Game Engine choisit de conserver un code rapide sans assembleur
  • Il peut cibler un large éventail de plateformes, de Windows, Linux et macOS jusqu’au mobile, aux consoles et au web, et dans Castle Game Engine, le code du moteur et le code du jeu sont écrits dans le même langage
  • Avec l’intégration de FPC, Lazarus, Delphi et VS Code, ainsi que la compatibilité avec diverses bibliothèques, il est possible de mettre en place un flux de développement pratique au sein de l’écosystème Pascal

Object Pascal, lisible et sûr grâce au typage

  • Object Pascal est présenté comme un langage multiplateforme moderne, lisible, rapide et sûr grâce au typage
  • Si vous connaissez déjà un autre langage orienté objet, il est relativement facile à apprendre, et vous pouvez utiliser Modern Object Pascal Introduction for Programmers comme ressource d’apprentissage
  • Il dispose des fonctionnalités attendues d’un langage orienté objet moderne
    • classes
    • unités
    • propriétés
    • génériques
    • interfaces
    • réflexion
    • fermetures
  • Sa syntaxe met l’accent sur un code facile à lire
  • Pour la sûreté du typage, il fournit des types distincts comme boolean, string, char, set, enum et range
    • Les conversions sûres, comme l’affectation d’un entier à un float, sont gérées facilement
    • Les autres conversions doivent être effectuées explicitement

Comment les erreurs sont détectées à la compilation et à l’exécution

  • Object Pascal accorde une grande importance aux vérifications à la compilation
  • Lors de refactorings, comme une réorganisation des structures de données, il est possible de faire en sorte que le compilateur révèle les endroits à modifier
  • Les erreurs évidentes, comme les fautes de frappe dans les noms ou les incompatibilités de type, ne passent pas la compilation et n’atteignent donc pas l’utilisateur
  • Des vérifications supplémentaires à l’exécution sont également disponibles
    • vérification des bornes des tableaux
    • vérification des dépassements d’entiers
    • assertion
    • détection des fuites mémoire
  • Les vérifications à l’exécution servent à détecter les problèmes dans les versions debug, et peuvent être désactivées dans les versions release où les performances sont importantes
  • Lors d’une compilation avec l’éditeur CGE, les modes debug / release sont configurés automatiquement, et il est possible de changer de mode depuis le menu “Run”
  • Vous pouvez consulter à ce sujet What are range and overflow checks (and errors) in Pascal et Detecting Memory Leaks

Performances natives et contrôle bas niveau à la demande

  • Object Pascal est compilé en code natif, ce qui facilite l’obtention de bonnes performances d’exécution de base
  • Dans les applications classiques, il est rarement nécessaire de descendre jusqu’aux optimisations bas niveau
  • Si besoin, il est possible d’utiliser autant de fonctionnalités bas niveau que souhaité
    • utilisation de pointeurs
    • arithmétique sur pointeurs
    • écriture de code spécifique à l’OS ou au CPU
    • ajout de code assembleur
  • Castle Game Engine vise une exécution rapide sans aucun code assembleur, afin d’améliorer la portabilité et la lisibilité du code
  • La compilation est également plutôt rapide : dans un cas observé, lors de la première ouverture d’un nouveau projet, un build desktop a pris 2,5 secondes et un build Android 10,1 secondes

Plusieurs plateformes et la méthode de développement de Castle Game Engine

  • Object Pascal peut être utilisé pour cibler de nombreuses plateformes
    • desktop : Windows, Linux, macOS, Raspberry Pi, FreeBSD, probablement tous les Unix
    • mobile : Android, iOS
    • consoles : Nintendo Switch
    • web : WebAssembly, JS via pas2js
  • Les plateformes prises en charge par Castle Game Engine sont listées sur Castle Game Engine platforms supported
  • Pour l’ensemble des cibles possibles, voir aussi FPC target platforms et Delphi target platforms
  • Dans Castle Game Engine, le code du moteur et le code du jeu sont écrits dans le même langage
  • Le moteur est open source, et il est possible de forker CGE pour le modifier selon ses besoins

Écosystème des bibliothèques et des outils de développement

  • Pascal dispose de nombreuses bibliothèques et unités existantes dans divers domaines
    • bases de données
    • XML, JSON
    • IA
    • blockchain
    • réseau
  • Il est facile d’intégrer ou de lier des bibliothèques existantes disposant d’une API C
    • moteurs de rendu
    • bibliothèques audio
    • moteurs physiques
  • Il est également possible d’utiliser Python libraries in Pascal
  • Les principaux outils de l’écosystème sont les suivants
    • FPC : compilateur open source Free Pascal Compiler
    • Lazarus : IDE Pascal open source basé sur FPC
    • Delphi : compilateur Pascal commercial et IDE
    • VS Code : plusieurs outils de l’écosystème CGE et Pascal prennent explicitement en charge l’intégration à VS Code

À lire aussi

3 commentaires

 
gmong 2023-07-20

Delphi... quelle nostalgie. Borland, Delmadang..
 
xguru 2023-07-10

À l’époque où je développais sous Windows, il me semble vraiment qu’Object Pascal avec Delphi était ce qu’il y avait de mieux.
 
GN⁺ 2023-07-10
Commentaires sur Hacker News

  • Si vous utilisiez Delphi autrefois, il y a de fortes chances que vous connaissiez déjà Lazarus. Lazarus est en pratique très proche d’une réimplémentation open source, et il s’exécute et se compile nativement presque partout, y compris sur des cartes ARM comme le Raspberry Pi
    Cela dit, l’installation des bibliothèques peut être pénible, donc FpcUp, puis FpcUpDeluxe, ont été créés pour automatiser l’installation de l’IDE, des modules et de quelques add-ons assez intéressants
    https://wiki.freepascal.org/fpcupdeluxe
    Il existe aussi une démo de widget de tableau de bord bricolée à la hâte avec les widgets gratuits inclus dans FpcUpDeluxe
    https://ibb.co/9bchx7T
    FpcUpDeluxe fonctionne aussi sur Alpine Linux, il suffit de prendre la version musl sur la page des releases. Cela ouvre donc la possibilité d’intégrer un tableau de bord même dans des systèmes très petits. Le code se compile nativement sur plusieurs plateformes et s’exécute rapidement, sans nécessiter d’interpréteur ni de navigateur web

  • J’ai un temps utilisé Delphi/Pascal comme langage principal, et j’ai passé les 10 à 20 dernières années à chercher le langage qui me conviendrait. J’ai aussi utilisé Haxe assez longtemps, mais j’ai fini par avoir l’impression de tomber dans le piège du « on peut faire ça avec une macro ». Les macros peuvent tout faire, mais quand il y en a suffisamment, tout le monde finit par programmer dans son propre langage d’extension par macros
    JavaScript a connu quelques bonnes améliorations, et il en faut encore, mais je fais aussi beaucoup de travail dans cet écosystème aujourd’hui. Il y a quelques années, en écrivant du code pour AVR 8 bits, j’ai réessayé FreePascal et j’ai vraiment pris du plaisir. En testant les nouvelles fonctionnalités, j’ai eu l’impression d’utiliser un langage vraiment moderne, et j’ai aussi apprécié le fait de viser un espace mémoire réduit, ce qui m’a amené à presque ne pas utiliser la bibliothèque standard et à écrire moi-même le code nécessaire
    Cela m’a permis d’éviter le bruit des espaces de noms accumulé au fil des années pour la compatibilité descendante dans FreePascal, avec par exemple des couches comme TList, TFPList, TFPGList et TFPGObjectList. Ma plus grande déception était que le compilateur n’autorisait pas les expressions constantes en virgule flottante sur des cibles sans FPU ni émulation. Comme cela pourrait être calculé à la compilation, j’aurais aimé que ce soit possible
    Après avoir utilisé d’autres environnements, le fait de ne plus pouvoir définir des variables au milieu d’une fonction me semble maintenant contraignant, et j’aimerais aussi avoir une portée au niveau des sous-fonctions. La différence entre begin/end et {} ne me dérange pas vraiment. Aujourd’hui, je préfère les langages sensibles à la casse, et je trouve mieux de ne pas préfixer les types avec des lettres. C’est surtout grâce aux progrès des éditeurs, à mon avis. La coloration syntaxique et le linting en temps réel déplacent ces informations vers une autre couche et réduisent le bruit visuel dans le texte
    Si un langage successeur de FreePascal repartait sur de nouvelles bases, je serais probablement très enthousiaste. J’aimerais une nouvelle bibliothèque standard qui traite les fonctionnalités modernes comme des citoyens de première classe, et peut-être que j’essaierai d’en créer une une fois à la retraite

    • begin/end et {} n’ont en fait pas exactement la même signification. {} définit une portée locale, alors que begin/end ne le fait pas

  • Dans les années 90, j’ai utilisé Delphi professionnellement pendant quelques années et j’aimais bien, mais j’ai fini par me lasser de voir Borland puis les propriétaires suivants mal gérer en permanence le produit et le langage. Anders Hejlsberg a lui aussi quitté Borland pour Microsoft, où il a créé C#, qui me semble personnellement être un langage et une architecture bien plus intéressants pour y investir son temps

    • Déployer de manière fiable une application desktop en C# est pratiquement un cauchemar par rapport au fichier exe unique produit par Delphi/Lazarus

  • Ces temps-ci, j’utilise Pascal par plaisir, à cause des contraintes de ressources. L’ancien Borland Turbo Pascal 3.00A tourne sur CP/M et fournit éditeur, compilateur et bibliothèques dans seulement 64 KB
    C’est largement assez rapide pour un usage interactif, et ça produit un code suffisant pour implémenter des utilitaires bas niveau, de petits jeux ou divers bricolages. Je n’ai jamais utilisé Pascal dans un environnement plus grand ou plus moderne, mais mon expérience récente a été assez satisfaisante pour que je n’aie pas l’intention de l’écarter

    • Turbo Pascal, puis Delphi plus tard, ont été le premier moment où un langage de programmation m’a vraiment parlé. J’ai fini par aller vers C et C++, mais j’ai toujours eu envie de revenir à un langage plus expressif
      Je ne savais même pas qu’il existait encore des implémentations modernes de Pascal, et il faudrait peut-être que je me rapproche de mon premier amour
    • Si vous ne l’avez pas encore essayé, ça vaut le coup de jeter un œil à Free Pascal. Il prend en charge de nombreuses plateformes
      Si vous avez besoin de CP/M, vous pouvez vérifier sur le site s’il est pris en charge, et même si c’est le cas, ça ne m’étonnerait pas. L’IDE en mode texte ressemble énormément à Turbo Pascal et il est ultra-rapide. Le langage possède bien plus de fonctionnalités avancées que Turbo Pascal, mais rien ne vous oblige à les utiliser
      Quand je l’avais testé rapidement sous Windows il y a quelque temps, les binaires produits étaient eux aussi très petits, comme en C, et un simple programme hello world faisait moins de 50 à 60 KB
    • Ah, la nostalgie de Pascal. À l’époque du TRS-80 Model III, j’avais économisé la coquette somme de 80 à 100 dollars pour acheter le package Pascal 80, version New Classics. C’était pratiquement un IDE avant l’heure, et c’était plutôt excellent pour l’époque. http://www.trs-80.org/pascal-80/
      Dans mon souvenir, c’était un progrès énorme par rapport à l’environnement de développement BASIC du M-III, et mes jeux et utilitaires maison tournaient plutôt bien même dans 48 KB de RAM. Je me demande ce qu’est devenue la base de code de Pascal-80. Elle ne peut sans doute pas être meilleure que les outils modernes pour matériel rétro, et probablement bien pire. “Oh Pascal!” est le livre avec lequel j’ai appris ce langage, et comme c’était quelques années avant que Pascal soit utilisé commercialement, il ne devait pas y avoir beaucoup d’autres options

  • J’ai du mal à être d’accord avec certaines raisons. Object Pascal n’est pas un langage moderne. Il l’était peut-être en 1998, mais il n’a pas beaucoup évolué depuis, et la dernière grande nouveauté a été les génériques, arrivés plus tard que dans presque tous les autres langages
    FPC ne génère pas un code particulièrement rapide, et les caractéristiques objet d’Object Pascal ne favorisent pas non plus la localité. C’est plus rapide qu’un langage de script, mais généralement plus lent qu’un langage compilé classique, même en incluant ceux avec ramasse-miettes
    En revanche, l’écosystème est excellent. Il y a beaucoup de bonnes bibliothèques et de bons outils, le plus notable étant Lazarus, un clone de Delphi. Les gens qui utilisent FPC ou Delphi ont en général tendance à se soucier assez peu de la modernisation du langage et à simplement faire le travail. Cela dit, je ne pense pas que ce soit très attirant pour de nouveaux développeurs, donc je ne sais pas ce qu’il en sera de l’avenir

    • Les génériques sont arrivés dans FPC il y a 17 ans, donc c’est loin d’être un changement récent. S’il faut citer une grosse évolution plus récente, les fonctions anonymes et les références de fonctions, autrement dit les closures, sont sans doute un meilleur candidat
      En pratique, les performances sont suffisantes, et si l’on trouve un goulot d’étranglement, on peut optimiser autant que nécessaire. Par rapport au C++, utiliser des classes plus « haut niveau » peut être un peu plus pénible, mais ce n’est pas impossible
      Si l’on veut de bonnes performances par défaut avec un minimum d’effort, il existe aussi un nouveau backend LLVM. En revanche, comme il faut compiler avec ce backend LLVM la bibliothèque d’exécution, la FCL, etc., il faut construire le compilateur depuis les sources, mais cela ne prend que quelques minutes. En contrepartie, le compilateur devient beaucoup plus lent, et personnellement je ne pense pas que le gain de performances en vaille la peine
    • Je pense que c’est sous-estimé. Il a déjà été benchmarké à une vitesse comparable à celle du C++, et pour son usage principal, les applications GUI locales, je n’ai jamais vu quoi que ce soit réagir aussi instantanément, y compris des applications GUI en C#
      Du coup, je me demande sur quel benchmark vous vous appuyez pour conclure que c’est 50 fois plus lent que la réalité
    • Je ne connais pas FPC, mais Delphi 7 était, il y a dix ans, à peu près au niveau du C++ en programmation compétitive, et environ 2 à 3 fois plus rapide que Java
      Ici, par programmation compétitive, j’entends des calculs algorithmiques courts, mono-thread, centrés sur le CPU, avec une limite d’environ 1 à 3 secondes par exécution, un contexte défavorable au JIT, et des réglages de compilateur/runtime par défaut, sans bibliothèques externes ni tuning. À l’époque, l’idée reçue était d’utiliser C++/Pascal, ou bien de coder en Java puis, si l’on obtenait “time limit exceeded”, de réécrire la solution de 200 à 300 lignes en C++ pour faire passer le test
    • La plus grande différence entre Pascal et C++, c’est l’expérience développeur
      Pascal utilise un compilateur LL(1) en un seul passage, ce qui permet des compilations en quelques millisecondes. Cela donne une expérience de type REPL où Edit→Compile→Run se termine en moins d’une seconde. Avec ses macros et ses temps de compilation lents, C/C++ offrait une moins bonne expérience développeur, et c’est du moins la raison pour laquelle j’ai appris Pascal au lieu de C, puis Delphi au lieu de C++
    • Je ne suis pas du tout d’accord avec l’idée que l’écosystème soit excellent. J’ai travaillé avec Pascal pendant environ dix ans, et le manque de bibliothèques modernes m’a souvent frustré, au point de devoir soit créer moi-même une solution, soit abandonner complètement l’idée

  • Je ne vois pas vraiment pourquoi il faudrait à tout prix faire ça. Les anciens langages doivent rester à cause du support legacy, mais je ne vois pas bien l’intérêt de greffer de force ce genre de fonctionnalités modernes sur un vieux langage
    J’utilise beaucoup Java, mais honnêtement, presque toutes les fonctionnalités ajoutées après Java 8 n’auraient pas dû l’être. Par exemple, les lambdas en Java tiennent davantage du bricolage
    Si on veut des fonctionnalités modernes, il suffit d’utiliser un langage moderne. Si on veut rester dans l’écosystème Java, on peut utiliser Kotlin. Je n’ai littéralement pas vu Pascal depuis des décennies, et la dernière fois que j’en ai fait remonte aux années 1980, donc je ne parle que de Java, mais ajouter ce genre de liste de fonctionnalités à Pascal paraît ridicule

    • Les lambdas, du bricolage ? Tu considères vraiment qu’il vaut mieux créer une classe anonyme avec une seule méthode ?
    • En Java, l’interopérabilité entre langages est facile, donc des choix comme Kotlin sont plus simples. Même chose pour Clojure. Mais si on est sur C++, il n’existe pas de voie simple pour évoluer vers autre chose
      Malgré tout, il y a un intérêt à y intégrer des fonctionnalités modernes. On peut choisir de ne pas démarrer un nouveau projet en C++ et prendre un langage moderne comme Rust, mais les millions de lignes de code C++ déjà écrites peuvent être améliorés par des fonctionnalités modernes. Il suffit de voir à quel point C++11 a changé la donne
    • Sinon, il faudrait changer de langage de programmation bien plus souvent. Ajouter et intégrer de nouvelles fonctionnalités dont les bénéfices ont été prouvés semble raisonnable si cela permet de retarder ce processus
    • Jusqu’à récemment, Java avait peu d’avantages sur Delphi d’il y a 15 ans, à part un écosystème absurdement vaste. Bien sûr, cet écosystème l’emporte sur tout le reste
      Le langage Java a produit une quantité énorme de code boilerplate à cause de sa décision de miser sur les bibliothèques plutôt que sur les fonctionnalités du langage, et je pense que c’était la mauvaise direction. Tout ce qui est faisable en Python, Lisp ou Haskell est aussi faisable en Java, mais par définition c’est aussi faisable en brainf*ck. La complexité des solutions Java réelles devient plus élevée que dans des langages plus riches en fonctionnalités, et au final on réimplémente ces fonctionnalités de langage d’une manière un peu cassée ou on importe une montagne de dépendances censées les remplacer. Dans les deux cas, cela ne fait qu’augmenter la surface d’API à apprendre
    • L’apparition de langages JVM compétitifs ne date que de ces dernières années. Scala était une impasse, Clojure relevait presque d’un effet de mode, et Rhino/JS avait des ambitions très limitées
      Les améliorations de Java ont permis à la JVM de rester pertinente et de contenir DotNet, ce qui était une bonne chose vu l’histoire de Microsoft

  • On l’oublie souvent, mais l’écosystème Ada embarqué a des atouts en matière d’analyse statique, de débogage et de maturité du support des cibles

    • J’ai toujours trouvé Ada sous-estimé. Personnellement, j’apprécie beaucoup ses fonctionnalités comme la sûreté mémoire, le modèle de concurrence standard, le support des types d’unités et de mesure, ainsi que la précompilation
      La syntaxe de style Pascal d’Ada peut paraître verbeuse, mais elle n’est pas difficile à lire. VHDL étant lui aussi basé sur une syntaxe Ada, cela peut être plus facile pour ceux qui utilisent les deux langages
      Swift coche aussi une partie de ces cases, et ajoute des fonctionnalités pratiques comme les closures, le comptage automatique des références et l’inférence de types. Je ne sais pas pour les types de mesure, mais cela semble faisable. En revanche, il ne semble pas encore exister d’HDL comparable en Swift
    • Je me demande si Ada prend désormais en charge les cibles Android et iOS. La dernière fois que j’ai regardé, il ne semblait pas y avoir de méthode claire pour compiler pour le NDK
    • Ce n’est pas l’option la plus accueillante pour démarrer sur macOS

  • Pascal est réellement bien et ses performances sont correctes. C’était le deuxième langage que j’ai appris au lycée après le Basic
    Je ne comprends pas pourquoi l’industrie a dû régresser vers Python, Ruby, Java, JavaScript à la fin des années 1990 et au début des années 2000

    • J’ai vu récemment une présentation sur ce sujet : https://www.youtube.com/watch?v=Tml94je2edk
      Elle explique pourquoi des langages à typage dynamique comme Python, Ruby et JS sont devenus populaires dans les années 1990 : ils offraient une boucle de feedback rapide pour créer des sites web, sans nécessiter d’IDE ni de compilateur. À l’époque, les IDE et les compilateurs étaient lents et souvent payants
      De toute façon, les utilisateurs se connectaient encore en modem 56k, donc échanger du temps de développement contre des gains de performance n’apportait pas grand-chose. La présentation contient aussi beaucoup de points intéressants sur l’évolution des pratiques de développement au cours des 10 à 20 dernières années et sur les raisons du retour vers le typage statique
    • Les ordinateurs sont devenus plus rapides et ont gagné en mémoire, donc il fallait bien trouver de quoi les occuper ;-)
      En outre, le navigateur web est devenu une plateforme de programmation populaire, utilisant principalement JavaScript. Même aujourd’hui, en plus de cette partie navigateur, on essaie encore d’y faire entrer de force un système d’exploitation complet, et Chrome s’en approche déjà pas mal

  • En première année d’université, mon premier projet était un simulateur d’ascenseur en Pascal, avec des graphismes en mode texte. Comparé aux langages de la famille C, il y avait dans Pascal une certaine élégance qui le rendait agréable
    C’est d’ailleurs pour cela que j’aime bien Nim aujourd’hui : à ma connaissance, Nim a été influencé non seulement par Ada et Python, mais aussi par Pascal, Modula-3, Oberon, Delphi et d’autres langages de la lignée de Wirth

  • Pascal n’est pas si mauvais, et je pense même qu’il a des avantages par rapport à certains langages modernes. Bien sûr, il n’est pas parfait et a aussi ses défauts
    Il m’arrive d’utiliser Pascal et BASIC pour programmer sous DOS, et au moins pour cet usage Pascal me paraît convenir. Le C est aussi utilisé pour la programmation DOS, mais il ne me semble pas particulièrement adapté, surtout en mode réel
    Pour programmer sous Linux, je préfère généralement le C, mais j’utilise aussi PostScript. Je pense que le C comme PostScript ont des avantages par rapport à certains langages modernes. Pascal peut aussi servir pour d’autres programmes, et même TeX a été écrit en Pascal

    • Je me demande à quoi tu utilises PostScript. Je trouve toujours intéressant de voir des gens s’en servir pour autre chose que l’impression