Discussion :

[gvasseur58]

Le compilateur Free Pascal vient d’être élu projet du mois de mai 2017 par la communauté de Sourceforge, ce qui n’était plus arrivé depuis avril 2014. C’est la récompense du travail fourni par toute une équipe et l’occasion pour Florian Klämpfl, l’initiateur du projet dont l’origine remonte à 1992, de rappeler les récents perfectionnements apportés au compilateur : la prise en charge des processeurs MIPS et JVM, les chaînes gérant les codes pages ainsi qu’une meilleure optimisation du code produit.

Par ailleurs, il annonce l’amélioration de la gestion des génériques et des progrès réalisés pour celle des méthodes anonymes. Dans le domaine des architectures visées, on notera les progrès relatifs à l’implémentation du compilateur pour Android, la famille Amiga ou les microcontrôleurs AVR, ce qui tend à montrer que la communauté Free Pascal travaille toujours tous azimuts. Parmi les projets les plus prometteurs, pastojs est chargé d’une traduction automatique des projets Pascal Objet en JavaScript et avance rapidement. C’est ainsi que Florian Klämpfl peut affirmer que Free Pascal « essaye de couvrir l’ensemble du spectre des plates-formes depuis le Z80 jusqu’à des technologies modernes comme le web assembly ».

L’entretien donné à l'occasion de cette élection se termine par une remarque que les habitués du forum Pascal developpez.com se font sans doute souvent : les sorties de nouvelles versions du compilateur sont rares ! Mais cette apparente lenteur de développement ne saurait cacher la vitalité d’un projet qui, rien que la semaine passée, a vu une centaine de contributions l’enrichir.

Source : SourceForge

Cette récompense vous paraît-elle justifiée ?
D'après vous, quelle place peut avoir un compilateur open source en 2017 ?
Quel avenir voyez-vous aux différentes pistes de développement avancées par Florian Klämpfl ?

[Invité]

Si je devais choisir en ce moment un langage compilé, pourvu d'une couche objet, rapide pour du calcul intensif, parallélisable et agréable à coder, est-ce que free Pascal ne serait pas finalement un meilleur choix que Rust, Julia, C++, ou D par exemple ?

[tomlev]

Mais qu'est-ce qu'il foutent encore sur SourceForge? Je suis étonné que ce site soit pas encore mort... C'était déjà pas terrible, mais depuis qu'ils mettent des downloaders qui installent des toolbars et assimilés, j'évite SourceForge comme la peste. De toute façon Github est bien meilleur sous tous rapports (à moins de vouloir absolument continuer à utiliser SVN, mais à quoi bon?)

[Songbird]

Si je devais choisir en ce moment un langage compilé, pourvu d'une couche objet, rapide pour du calcul intensif, parallélisable et agréable à coder, est-ce que free Pascal ne serait pas finalement un meilleur choix que Rust, Julia, C++, ou D par exemple ?

Sur la liste des langages que tu proposes, je ne vois pas ce qui te fait dire que free pascal serait un meilleur choix.

[Invité]

Sur la liste des langages que tu proposes, je ne vois pas ce qui te fait dire que free pascal serait un meilleur choix.

Ben c'est là la question justement. C'est une façon indirecte de poser la question de ce en quoi free Pascal serait mieux ou moins bien que les autres langages mentionnés

[Songbird]

Ben c'est là la question justement. C'est une façon indirecte de poser la question de ce en quoi free Pascal serait mieux ou moins bien que les autres langages mentionnés

Ah, mes excuses, je n'avais pas compris de cette manière.

Donc pour te répondre: je n'en sais rien. Beaucoup de langages ont poussé en quelques années pour proposer des outils plus "modernes" pour faire du bas niveau et je n'en étudie qu'un seul jusqu'ici (Rust).
La sélection naturelle fera son boulot pour trancher dans les langages qui resteront.

[Jiji66]

Julia est trop spécialisé pour pourvoir être comparé à du Rust du C++ du D ou du Pascal-Object.
D et Rust essayent de rendre C++ plus 'safe' pour ceux qui programment mal, Pour le reste je suis d'accord avec le fait que la sélection naturelle fera inévitablement son travail en éliminant les jeunes tentacules rouillés du C++.

[Jiji66]

Si je devais choisir en ce moment un langage compilé, pourvu d'une couche objet, rapide pour du calcul intensif, parallélisable et agréable à coder, est-ce que free Pascal ne serait pas finalement un meilleur choix que Rust, Julia, C++, ou D par exemple ?

Julia semble avoir été créé avec l'objectif affiché de satisfaire ceux qui veulent faire du calcul intensif. Pour ce genre de besoin c'est à mon avis le meilleur choix.

Maintenant si l'objectif est d'avoir une application multi plate forme qui fasse de gros calculs tout en accedant au bas niveau et rester en programmation Object sur le reste de l'application je dirais que C++ ou Free-Pascal sont de bons choix.

Maintenant attention, on ne programme pas en C comme en C++ ou comme en Pascal-Object de la même façon, chacun des trois demande un investissement personel spécifique.

[Invité]

Merci pour vos réponses à tous les deux
Je connais déjà bien le Pascal objet, C et C++ pour les avoir utilisés et enseignés durant de nombreuses années. Je connais un peu pour les avoir testés Rust et D. Quant à Julia j'ai essayé de m'y mettre il y a quelques mois mais je dois avouer que j'ai été déconcerté par la syntaxe que j'ai trouvée assez rigide ... prix à payer pour avoir un code efficace en calcul intensif j'imagine.
Comme je développe essentiellement des applis académiques appliquées à une problématique donnée j'ai une grande latitude dans le choix de mes outils et à lire vos réponses je vois bien que je n'ai pas d'intérêt particulier (en dehors du plaisir de la découverte d'un langage) à approfondir Rust ou D car pour ce que je fais, ils n'apporteront pas une grande valeur ajoutée.

Darwin rules

[BenaeSan]

@tomlev

j'avais trouvé cet article intéressant sur les dangers de l'utilisation d'un site du genre de Github pour l'hébergement des sources des projets libres.

https://carlchenet.com/le-danger-git...u-et-augmente/

Je suis surpris aussi, mais il reste quelques projets sur Sourceforge, comme 7-zip, dolibarr etc.

[tomlev]

j'avais trouvé cet article intéressant sur les dangers de l'utilisation d'un site du genre de Github pour l'hébergement des sources des projets libres.

https://carlchenet.com/le-danger-git...u-et-augmente/

Intéressant, merci pour le lien. Dans l'ensemble je trouve ça un peu parano, mais il y a quelques points assez justes, notamment sur l'uniformisation.

[Songbird]

D et Rust essayent de rendre C++ plus 'safe' pour ceux qui programment mal

Là par contre, je ne suis absolument pas d'accord. C'est comme dire "Java a été inventé parce que les devs sont incapables de gérer leurs ressources sans tout faire exploser".
Sinon, qu'est-ce que ça veut dire pour toi, quelqu'un qui programme mal ?

[pvincent]

Mais qu'est-ce qu'il foutent encore sur SourceForge? ... depuis qu'ils mettent des downloaders qui installent des toolbars et assimilés, j'évite SourceForge comme la peste.

En fait, après avoir cédé un temps à de mauvaises pratiques, le site a fait des excuses et il est revenu à une politique moins agressive.

[Jiji66]

Là par contre, je ne suis absolument pas d'accord. C'est comme dire "Java a été inventé parce que les devs sont incapables de gérer leurs ressources sans tout faire exploser".
Sinon, qu'est-ce que ça veut dire pour toi, quelqu'un qui programme mal ?

C++ est ce qu'il est : Permissif. Les principaux problèmes rencontres par les développeurs concernent la gestion de la mémoire et la validité des pointeurs; D et Rust chacun de leurs cotés essayent d'apporter des réponses ou en rajoutant des contraintes ou des actions automatiques (libration automatique de ressources).

Ces 'extras' facilitent la vie des développeurs qui ne désirent pas surveiller la gestion de leurs ressources matérielles; dans tous les cas ça a un prix en terme de performances et peut même être incompatible avec des applications qui ont des contraintes temporelles externes.

Pour ce qui concerne Java il y a comme toujours beaucoup de choses à dire et d'encre à faire couler. Les fans le regardent un peu trop comme une solution universelle et les autres un peu trop comme un ogre tentaculaire qui s’octroie de façon opaque les ressources disponibles (heureusement contenues dans des machines virtuelles). Au final tout dépends de l’œil de celui qui regarde;

[Songbird]

Ces 'extras' facilitent la vie des développeurs qui ne désirent pas surveiller la gestion de leurs ressources matérielles; dans tous les cas ça a un prix en terme de performances et peut même être incompatible avec des applications qui ont des contraintes temporelles externes.

Tu aurais des exemples ?

[Jiji66]

Tu aurais des exemples ?

Le cas du "garbage collector" est classique. La disponibilité des ressources n'est pas directement contrôlée et peut très bien ne pas se faire suffisamment tôt pour la prochaine allocation qui devra attendre une libération du -> "garbage collector". Même en supposant que la disponibilité mémoire ne soit pas un problème il reste celui de la disponibilité immédiate des canaux de communications. De façon générale tout processus qui n'est pas déterministe peut poser un problème a un moment ou un autre dans le cas d'une application avec qui doit elle jouer avec des contraintes temporelles précisément déterminées.

Pour le reste je dirais que le C++ peut très bien être enrichi des bibliothèques qui vont bien pour faire du "garbage collector" sans pour autant inventer un nouveau langage.

Sans que ce soit général, j'ai l'impression qu'il y a bien souvent des inventions de langages qui sont faites pour répondre spécifiquement a un "type" d'applications données avec à la clef la perte d'universalité. Pour l'avoir pratiqué un peu le langage R me semble bien représentatif de ce genre d'exemple; Les ressources y sont allouées de façon magique et les utilisateurs sont juste éblouis par la diversité des bibliothèques de calculs ou graphiques au point qu'ils ne raisonnent plus qu'a travers çà. l’équivalent pourrait très bien se faire en C++ avec des bibliothèques idoines.

La cas du Fortran est lui aussi intéressant car très utilisés par les scientifiques. J'ai connu des gens qui m'expliquaient qu'on ne pouvais pas nativement faire de calcul matriciel en C et que c’était pour cette raison qu'ils utilisaient du Fortran ..... C'est un choix que je respecte mais c'est au prix d'une perte de ce que j’appelle l’universalité du langage car tout ce qui est fait en Fortran peut être fait en C mais pas l'inverse...

Ce sont les raisons pour lesquelles je regarde avec prudence toute apparition d'un nouveau langage qui cherche a conserver la syntaxe du C ou du C++. Au final ou est l’amélioration ? dans le fait qu'il n'est pas nécessaire d'inclure de nouvelles bibliothèques ?

[Songbird]

Le cas du "garbage collector" est classique. La disponibilité des ressources n'est pas directement contrôlée et peut très bien ne pas se faire suffisamment tôt pour la prochaine allocation qui devra attendre une libération du -> "garbage collector". Même en supposant que la disponibilité mémoire ne soit pas un problème il reste celui de la disponibilité immédiate des canaux de communications. De façon générale tout processus qui n'est pas déterministe peut poser un problème a un moment ou un autre dans le cas d'une application avec qui doit elle jouer avec des contraintes temporelles précisément déterminées.

Mes excuses, quand je te demandais des exemples d'incompatibilité, je parlais d'un langage moderne comme Rust ou D (puisque nous en parlions). Ces langages n'utilisent aucun garbage collector (edit: D en utilise un, autant pour moi. Je ne parle que de Rust dans ce cas).

Sans que ce soit général, j'ai l'impression qu'il y a bien souvent des inventions de langages qui sont faites pour répondre spécifiquement a un "type" d'applications données avec à la clef la perte d'universalité. Pour l'avoir pratiqué un peu le langage R me semble bien représentatif de ce genre d'exemple; Les ressources y sont allouées de façon magique et les utilisateurs sont juste éblouis par la diversité des bibliothèques de calculs ou graphiques au point qu'ils ne raisonnent plus qu'a travers çà. l’équivalent pourrait très bien se faire en C++ avec des bibliothèques idoines.

Je n'ai jamais fait de R, donc je ne pourrais pas répondre vis-à-vis de la "compatibilité" entre le C++ et le R. Toutefois, tu pars du principe que tout devrait tourner autour du C++: pourquoi cela devrait-il être fait en C++ ?
Si ce qui est fait avec R peut être fait avec C++, alors il y a tout autant d'intérêt à travailler avec l'un ou l'autre, non ? (ce sont de véritables questions)

Ce sont les raisons pour lesquelles je regarde avec prudence toute apparition d'un nouveau langage qui cherche a conserver la syntaxe du C ou du C++. Au final ou est l’amélioration ? dans le fait qu'il n'est pas nécessaire d'inclure de nouvelles bibliothèques ?

Pour ma part, je trouve que le C++ demande un (très) gros investissement de la part du développeur, pour arriver au même résultat que dans un autre langage, pour être productif. Je vois aussi un autre souci, qui pousse (ou tout du moins, qui me pousse) les développeurs à utiliser un autre langage: C++ est très ambigu, il y a 100 façons de faire les choses et c'est ce qui fait sa force comme sa faiblesse, à mon avis. Le fait qu'on puisse mélanger la syntaxe (et les modules) du C, même lorsque l'on souhaite faire uniquement du C++ (pour apprendre), là où les langages modernes sont, par définition, plus jeunes, donc moins marqués par les modifications et peut-être moins compliqués.
La gestion des projets aussi, des dépendances. Personnellement, j'ai vraiment du mal avec la gestion de projet C++, là où maven (pour Java) et cargo (pour Rust) proposent de gérer les projets en suivant un modèle de projet prévu (qui est totalement configurable, et peut donc être modifié, mais reste tout de même présent si il n'est pas nécessaire d'y toucher), de gérer les dépendances d'une autre manière (e.g. téléchargement et compilation automatiques de projets se trouvant sur un dépôt git, pour cargo).

Je ne pense pas que ça soit une simple question de bibliothèques (si ce n'était que ça, nous serions certainement tous en train de coder en C).

Très bonne journée à toi!

[Jiji66]

Mes excuses, quand je te demandais des exemples d'incompatibilité, je parlais d'un langage moderne comme Rust ou D (puisque nous en parlions). Ces langages n'utilisent aucun garbage collector (edit: D en utilise un, autant pour moi. Je ne parle que de Rust dans ce cas).

Je n'ai jamais fait de R, donc je ne pourrais pas répondre vis-à-vis de la "compatibilité" entre le C++ et le R. Toutefois, tu pars du principe que tout devrait tourner autour du C++: pourquoi cela devrait-il être fait en C++ ?
Si ce qui est fait avec R peut être fait avec C++, alors il y a tout autant d'intérêt à travailler avec l'un ou l'autre, non ? (ce sont de véritables questions)


Pour ma part, je trouve que le C++ demande un (très) gros investissement de la part du développeur, pour arriver au même résultat que dans un autre langage, pour être productif. Je vois aussi un autre souci, qui pousse (ou tout du moins, qui me pousse) les développeurs à utiliser un autre langage: C++ est très ambigu, il y a 100 façons de faire les choses et c'est ce qui fait sa force comme sa faiblesse, à mon avis. Le fait qu'on puisse mélanger la syntaxe (et les modules) du C, même lorsque l'on souhaite faire uniquement du C++ (pour apprendre), là où les langages modernes sont, par définition, plus jeunes, donc moins marqués par les modifications et peut-être moins compliqués.
La gestion des projets aussi, des dépendances. Personnellement, j'ai vraiment du mal avec la gestion de projet C++, là où maven (pour Java) et cargo (pour Rust) proposent de gérer les projets en suivant un modèle de projet prévu (qui est totalement configurable, et peut donc être modifié, mais reste tout de même présent si il n'est pas nécessaire d'y toucher), de gérer les dépendances d'une autre manière (e.g. téléchargement et compilation automatiques de projets se trouvant sur un dépôt git, pour cargo).

Je ne pense pas que ça soit une simple question de bibliothèques (si ce n'était que ça, nous serions certainement tous en train de coder en C).

Très bonne journée à toi!

Justement, la réciprocité n'est pas assurée. Tout ce qui peut être fait en R peut être fait en C++ mais pas l'inverse. Comme tu le remarques, plus un language est permissif et plus il y a de chemins possibles pour faire quelque chose avec, mais il est facile de s'égarer dans des voies inutilement compliquées et facile de choisir des solutions qui sont mauvaises gestionaires des ressources disponibles. C'est en ce sens que je disais que les "nouveaux" languages essayent de compenser les faiblesses des programmeurs.

Il est clair que s'investir dans un language représente du travail et présente le risque d'y être prisonier de sa technologie et donc des applications pour lesquelles il est plus spécialisé. L'universalité ce n'est pas facile ....

Java est un exemple interessant ou la logique a été de créer un environnement virtuel qui se veut universel dans lequel tout programme Java est sencé pouvoir fonctionner. La réalité est bien sur moins idéale que prévue avec (de mon point de vue) une débauche de ressources nécessaires pour écrire un "Bonjour le Monde"; De plus Oracle reste le grand ordonateur de la chose ce qui peut potentiellement présenter un risque pour la disponibilité future.

Pour ma part je suis un adepte autant que possible du pascal object et du compilateur FreePascal qui permet en natif de faire des executables sur un large éventail de plate formes matérielles.

Nous sommes bien d'accord que tout n'est pas qu'une question de bibliothèques mais aussi de compilateurs qui ont eux aussi leurs limitations. On ne compile pas ou ne programme pas de la même façon sur des machines mono processeurs ou massivement parallèles.

Bien à toi,
Jean-Michel

[M.Dlb]

À quand un portage de FreePascal pour la z/Architecture ?? Ça serait le pied !!

[Invité]

Tout ce qui peut être fait en R peut être fait en C++ mais pas l'inverse.

C'est parfaitement exact, ceci dit ça peut être également fait en assembleur mais ce n'est pas pour autant la preuve que l'assembleur est plus efficace que R pour faire des stats

Pour ma part je suis un adepte autant que possible du pascal object et du compilateur FreePascal qui permet en natif de faire des executables sur un large éventail de plate formes matérielles.

Idem, c'est un excellent outil mais on ne peut pas se contenter d'un seul. De même qu'on ne peut pas abattre un gros arbre avec un Opinel n°10, il est difficile de lever des filets de poisson avec une tronçonneuse