Discussion :

[DonQuiche]

L'objectif du langage Pascal n'était pas celui du C, à savoir écrire des sources les plus petites possibles.

Son objectif n'est pas non plus la verbosité, celle-ci n'étant vue comme désirable par Pascal que lorsqu'elle sert la lisibilité. Or un code basé sur "yield return" est infiniment plus lisible et clair qu'un code basé sur une mise en oeuvre manuelle.

Tout ce que j'ai mentionné, du couple async/await au "yield return", est aux problèmes concernés ce que la programmation structurée était aux branchements. Or la syntaxe Pascal avait été conçue pour mettre en évidence ces structures. Pour cette raison, si Pascal était inventé aujourd'hui, il se ferait un devoir d'adopter ces mécanismes qui correspondent parfaitement à sa philosophie initiale : une syntaxe mettant en évidence des structures de haut niveau.

encore une fois ne mélangeons pas Pascal le langage et les IDE permettant le RAD, même si ceux-ci sont de plus en plus liés .

Je me revendique du camp de ceux qui pensent qu'un langage de programmation est avant tout une expérience utilisateur qui doit prendre en compte les outils et bibliothèques disponibles. C'est toutefois un sujet qui divise les acteurs du développement logiciel.

il faut faire une recherche avec le terme Firemonkey (et accessoirement Delphi+Firemonkey) plutôt que FMX et la réponse devient tout de suite plus "ouverte" ou tout simplement télécharger la version d'évaluation de Delphi XE8 pour s'y frotter

Merci à toi !

http://www.gerixsoft.com/blog/delphi/yield

Non seulement ta solution s'appuie sur une vaste et complexe bibliothèque pour en arriver à ce résultat, mais surtout elle passe par des green threads, ce qui va causer de nombreux bogues difficiles à comprendre (parce qu'elle est incompatible avec les codes s'appuyant sur le thread-local storage), des problèmes de portabilité (les green threads sont mal supportés par certains OS, y compris soi-disant posix) et de gros problèmes de performances (sauf dans les cas d'itérateurs à plusieurs niveaux). Et ce bricolage non-portable, lent et bogué reste syntaxiquement plus moche que la solution standard trouvée en C#.

Aucun langage à ma connaissance ne passe par des green threads pour ses itérateurs. Il y a une bonne raison à cela. Beaucoup ont pourtant essayé, tous sont revenus sur d'autres solutions.

Le reste est du même acabit : du bricolage bourré de problèmes et non-intégré au langage et à son écosystème. Tu te contentes de fournir le premier lien Google pour dire que Pascal a résolu le problème et nier ce dernier.

Les évolutions importantes, utiles et qui apportent réellement quelque chose (une réponse à un besoin fonctionnel, une simplification pour le développeur...) sont tôt ou tard reprises dans les autres langages.

Les systèmes comme "yield" ou "await" ne font pas débat : ils ont été repris dans de nombreux langages, davantage de langages encore projettent de les adopter et tout le monde en général en reconnait l'utilité. Sauf toi apparemment. Je te laisse conclure quant à l'impression que cela me donne.

Je précise qu'il s'agit d'un livre qui s'adressera aux programmeurs non experts mais désireux de progresser. Il complète un premier tome qui s'intéressait notamment à : Generics, Interfaces, Exception Handling, Anonymous Methods, Collections, RTTI, Enumerators, Attributes, Dependency Injection and Unit Testing. Est-ce que l'énumération de ces sujets mérite un haussement d'épaules accompagné d'un "trop trivial", "dépassé", "archaïque" ?

Archaïque ? Non. Mais cette table des matières aurait pu exister presque telle quelle en 1990. Et plus encore le contenu de nombre de ces chapitres sera décevant par rapport à celui des chapitres idoines d'autres langages.

Je ne dis pas que les fonctionnalités de Pascal sont archaïques, ce sont ses manques qui le sont. Je dis que les langages modernes ont tout ce contenu, et bien plus encore.

En fait, si (comme tu le suggères), Pascal devait être cantonné à un langage d'apprentissage, je le préfèrerais à d'autres réputés faciles mais qui poussent à la "faute" (je pense à PHP, par exemple), et encore à d'autres qui n'incitent pas à écrire du code lisible et réutilisable quand il est confié à des programmeurs qui travaillent à l'abattage (je pense au C, C++...).

Tu retombes encore dans l'argument selon lequel les programmeurs Pascal seraient supérieurs. Cette fois ce serait parce qu'ils écrivent du beau code. Et bien non, désolé, un code bien écrit et organisé et une syntaxe conçue pour la lisibilité sont deux choses disjointes.

Par ailleurs si Pascal a une syntaxe qui met en évidence les structures de contrôle, il a aussi des travers qui nuisent à la lisibilité, par exemple le fait de déclarer les variables en en-tête de la fonction plutôt qu'au plus près de leur utilisation. Un choix qui se justifiait quand la pile d'appels était de 1024 octets mais qui va à l'encontre des bonnes pratiques reconnues aujourd'hui.

Bon, je ne sais toujours pas ce que tu pratiques comme langage en ce moment. Je pencherais pour Java ou C#, je me trompe ?

Mon principal langage ces quinze dernières années a été C#, aujourd'hui je travaille surtout sur un langage plus avancé et qui n'est pas encore public.
Avant cela ça a été C/C++ et Pascal, et j'ai par ailleurs touché à bien d'autres langages (php, js, java, vb6, etc) et d'autres moins répandus (Rust, Haskell, OCaml, Chapel, Erlang, etc).

[gvasseur58]

Archaïque ? Non. Mais cette table des matières aurait pu exister presque telle quelle en 1990. Et plus encore le contenu de nombre de ces chapitres sera décevant par rapport à celui des chapitres idoines d'autres langages.

Tu le fais exprès ? Tu commentes l'ancien livre (pour débutants) et pas le nouveau Quant à la seconde affirmation, elle a la valeur d'une affirmation, pas plus.

Je ne dis pas que les fonctionnalités de Pascal sont archaïques, ce sont ses manques qui le sont. Je dis que les langages modernes ont tout ce contenu, et bien plus encore.

Le problème auquel se heurte Nick Hodges (et bien d'autres avec lui) est tout simplement que nombre de programmeurs n'utilisent pas les fonctionnalités les plus novatrices. Tu pourras ajouter "bien plus encore", rien ne fera que les programmeurs adopteront automatiquement ton innovation.

Tu retombes encore dans l'argument selon lequel les programmeurs Pascal seraient supérieurs. Cette fois ce serait parce qu'ils écrivent du beau code. Et bien non, désolé, un code bien écrit et organisé et une syntaxe conçue pour la lisibilité sont deux choses disjointes.

On fait la paix et voilà comment on est traité . Je n'ai jamais écrit ce qui précède ou c'en est une lecture pour le moins déformée.

Par ailleurs si Pascal a une syntaxe qui met en évidence les structures de contrôle, il a aussi des travers qui nuisent à la lisibilité, par exemple le fait de déclarer les variables en en-tête de la fonction plutôt qu'au plus près de leur utilisation. Un choix qui se justifiait quand la pile d'appels était de 1024 octets mais qui va à l'encontre des bonnes pratiques reconnues aujourd'hui.

C'est vrai, il n'existe pas de langage parfait et je n'ai jamais prétendu que Pascal l'était. Il est seulement moins pire que d'autres et sans doute moins bien que d'autres (concernant la lisibilité, je demande à voir).

Mon principal langage ces quinze dernières années a été C#, aujourd'hui je travaille surtout sur un langage plus avancé et qui n'est pas encore public.
Avant cela ça a été C/C++ et Pascal, et j'ai par ailleurs touché à bien d'autres langages (php, js, java, vb6, etc) et d'autres moins répandus (Rust, Haskell, OCaml, Chapel, Erlang, etc).

Merci pour ta réponse. Je te souhaite une bonne réussite avec ton langage nouveau. J'imagine que tu (vous pour une équipe) auras pris en compte l'attente des programmeurs : un langage adapté aux besoins, simple, efficace, puissant, facile (ce qui n'a rien à voir avec la simplicité), maintenable et pérenne

[DonQuiche]

Tu le fais exprès ?

Je pense avoir fait beaucoup d'efforts dans cette discussion face à votre hostilité commune, j'aimerais vraiment que la majorité d'entre vous reconsidèrent leur appréciation de la courtoisie.

Tu commentes l'ancien livre (pour débutants) et pas le nouveau

Le commentaire s'applique aux deux, j'ai simplement choisi la citation la plus courte.

Le problème auquel se heurte Nick Hodges (et bien d'autres avec lui) est tout simplement que nombre de programmeurs n'utilisent pas les fonctionnalités les plus novatrices.

Pourtant ils l'ont fait dans les autres langages, et je vois qu'en C#, Java, Php ou C++ les nouveautés sont très rapidement adoptées. Même en Javascript en dépit des problèmes de compatibilité plus importants !

Alors si le diagnostic est réel en Pascal, à quoi cela pourrait-il être dû d'après toi ? Problèmes de mise en oeuvre ? Écosystème antérieur incompatible avec ces additions qui réclament souvent un écosystème conçu pour elles dès le départ ? Utilisateurs plus conservateurs que la moyenne ?

Je te souhaite une bonne réussite avec ton langage nouveau. J'imagine que tu (vous pour une équipe) auras pris en compte l'attente des programmeurs : un langage adapté aux besoins, simple, efficace, puissant, facile (ce qui n'a rien à voir avec la simplicité), maintenable et pérenne

Pour commencer qui a dit que c'était mon/nôtre langage et pas celui d'un tiers ?

Quant aux attentes des utilisateurs...
a) Voir la citation de Ford sur les consommateurs qui demandaient des chevaux plus rapides plutôt que des voitures.
b) Les fonctionnalités désirables dépendent de ses objectifs et des domaines d'application.
c) Cette discussion a prouvé que les adjectifs que tu as énuméré, bien que d'un bon sens apparent, sont en fait interprétés de façon très différente d'un individu à l'autre.

[gbegreg]

Non seulement ta solution s'appuie sur une vaste et complexe bibliothèque pour en arriver à ce résultat, mais surtout elle passe par des green threads, ce qui va causer de nombreux bogues difficiles à comprendre (parce qu'elle est incompatible avec les codes s'appuyant sur le thread-local storage), des problèmes de portabilité (les green threads sont mal supportés par certains OS, y compris soi-disant posix) et de gros problèmes de performances (sauf dans les cas d'itérateurs à plusieurs niveaux). Et ce bricolage non-portable, lent et bogué reste syntaxiquement plus moche que la solution standard trouvée en C#.

Aucun langage à ma connaissance ne passe par des green threads pour ses itérateurs. Il y a une bonne raison à cela. Beaucoup ont pourtant essayé, tous sont revenus sur d'autres solutions.

Ce n'est pas ma solution mais une solution (qui date de 2013).
Comme je l'ai déjà dit, je n'ai qu'une petite expérience des threads. Sais tu comment est implémentée l'instruction yield en C# ? Ne s'appuie t'elle pas sur une vaste et complexe bibliothèque ? Dès qu'on touche aux threads on peut rencontrer des bogues difficiles à comprendre. Comment peux tu dire que "ce bricolage lent et bogué" sans l'avoir testé ?

Tu reproches également la non portabilité : c'est vrai d'ailleurs l'auteur l'indique car il s'appuie sur les fibres Windows. Mais si on utilise des threads natifs la portabilité en prendra aussi un coup non? Comme tu fais du C#, sa portabilité est un peu limitée par rapport à celle de Java, non ?

Pour info, Delphi XE8 dispose en standard de la méthode yield (mais je ne l'ai pas mentionnée car je ne sais pas si c'est valable pour tous les compilateurs Pascal) et c'est comme pour Java pour les threads (classes TThread et TMonitor par exemple).

Enfin, la notion de beauté de la syntaxe est subjective...

Le reste est du même acabit : du bricolage bourré de problèmes et non-intégré au langage et à son écosystème. Tu te contentes de fournir le premier lien Google pour dire que Pascal a résolu le problème et nier ce dernier.
Les systèmes comme "yield" ou "await" ne font pas débat : ils ont été repris dans de nombreux langages, davantage de langages encore projettent de les adopter et tout le monde en général en reconnait l'utilité. Sauf toi apparemment. Je te laisse conclure quant à l'impression que cela me donne.

Je ne dis pas que Pascal a résolu le problème, j'essaye juste de montrer qu'il existe des moyens en Pascal d'y répondre également. Je ne nie pas le besoin non plus : chaque problème a plusieurs solutions. Je m'arrête au premier lien renvoyé par Google ? Non, il en renvoie de nombreux ! D'ailleurs, tu aurais pu faire des recherches toi aussi avant de poster certaines remarques (sans reprendre toute la discussion : quand tu dis que WinDev est un vrai RAD en précisant certains points, saches que Delphi fait pareil, les lambdas fonctionnent, utilisation du GPU en Pascal est possible, le yield est possible ne t'en déplaise...).

Je ne cherche pas à savoir que tel langage est meilleur qu'un autre : c'est un débat stérile et chacun à ses forces et faiblesses. La critique est toujours bonne et sur certains points tu as raison. Mais ce que j'ai du mal à comprendre c'est comment à partir d'un postulat faux (ou d'une idée reçue, ou d'une expérience qui date un peu (dans ton cas sur le Pascal)), on peut affirmer des choses en disant que c'est la vérité sans avoir vérifié un minimum avant...

Un point qui n'est pas abordé dans cette discussion : les pré-requis nécessaires aux binaires générés. Un exécutable compilé en Pascal (mais ce n'est pas le seul) fonctionne directement sur une machine (il n'y a pas besoin de runtime ou de framework particulier en plus de l'OS comme c'est le cas pour Java ou C#).

[sergio_is_back]

voilà du n'importe quoi , le Pascal Objet un langage d'avenir......

Voilà les langages d'avenir :

Java
Javascript
C#

et puis c tout ......

ça c'est une vision de l'avenir...

Franchement quand tu bosses pour des clients tu ne choisi toujours ton langage, pour ma part je développe avec Delphi depuis plus 15 ans mais aussi avec d'autres langages (C++, C, VB.NET, Java, Php, un peu de C#, et même de l'assembleur sur des micro-controleurs), tu choisi le langage adapté à la plateforme, au projet et quelques fois c'est le client qui exige que ton dév soit fais avec le langage (ou l'IDE) maison (j'ai du faire aussi du WinDE parfois).

Quant à Delphi il est toujours très présent dans l'industrie (automatismes, machines outils) et il est très apprécié en terme de stabilité et de vélocité des applications, ne pas avoir de gestion automatisée de la mémoire c'est pas rédhibitoire bien au contraire ça oblige à bien coder les choses pour que toutes les instances allouées soit bien libérées. Dans l'industrie on trouve encore des machines avec moins d'1 GO de mémoire et XP Pro et XP Embedded sont encore très présents. De plus Delphi dispose d'un écosystème très vaste (dizaines de milliers de composants/contrôles gratuits). De plus Delphi est un langage très ouvert et la communication avec tous les types de bases données, les protocoles de bus de terrains et le système d’exploitation est d'une remarquable simplicité et d'une grande stabilité (ce qui n'est pas toujours le cas avec .NET ou Java)

Alors, non c'est pas un langage du passé, et le signe qu'il continue à évoluer est une bonne chose, réduire l'informatique à la programmation managée c'est méconnaitre tout un pan du travail de développeur (surtout quand comme moi on ne développe que des moutons à 5 pattes)

[ALWEBER]

Pascal Objet pourrait-il booster votre carrière ?
Un analyste constate que c'est le langage dont la demande a le plus augmenté en 2013-2014 aux USA...

Sources :
...[*]Le blog d'ALWEBER (http://www.developpez.net/forums/blo...uvelles-monde/)[/list]
...

Un grand merci à Alcatîz pour avoir permis la diffusion de cette information que j'avais proposé de mettre en actualité depuis mon blog.

A partir XE2 nous avons deux environnements : VCL bien connu des utilisateurs de DELPHI et ce nouveau modèle Firemonkey nommé FMX.
Petit rappel : dans l'histoire de la société Borland qui a créé Turbo Pascal devenu ensuite Delphi, il y a à la fin des années 80 une volonté de concurrencer Microsoft et de développer un système d'exploitation fenêtré avec gestion d'évènements de souris, de clavier, etc. Finalement MS-Windows s'imposera. Aujourd'hui l'adoption de la technologie FMX répond certainement à une volonté similaire d'autonomie. Cette évolution permet de prendre plus de recul par rapport aux systèmes d'exploitation en vue d'une plus grande ouverture avec du client riche multi OS. Une des conséquences plus imprévues de cette intégration est liée à la 3D. FMX encapsule totalement les bibliothèques graphiques OpenGL ou Direct3D. Il est ainsi possible de programmer dans un langage homogène Pascal Objet et les graphiques et l'animation de ces graphiques. Il est possible de repenser entièrement le bureau virtuel de travail pour un meilleur confort de l'utilisateur comme semblent le faire les grandes entreprises mondiales qui développent les systèmes d'exploitations. (IBM en Inde recherchait à ce sujet des développeurs Delphi). L'industrie est aussi très concernée par ces évolutions et les applications précédemment souvent développées avec Delphi/C++ et OpenGL peuvent aujourd'hui être réécrites avec FMX.

A titre d'exemple ce tore créé de toutes pièces en une centaine de lignes de code

[matthius]

Il est ainsi possible de programmer dans un langage homogène Pascal Objet et les graphiques et l'animation de ces graphiques.
Il est possible de repenser entièrement le bureau virtuel de travail pour un meilleur confort de l'utilisateur comme semblent le faire les grandes entreprises mondiales qui développent les systèmes d'exploitations. (IBM en Inde recherchait à ce sujet des développeurs Delphi)
L'industrie est aussi très concernée par ces évolutions et les applications précédemment souvent développées avec Delphi/C++ et OpenGL
peuvent aujourd'hui être réécrites avec FMX.

Sur Lazarus, la LCL permet de créer des interfaces iOS, puis Android. La VCL de DELPHI XE5, forcément inspirée elle aussi de Lazarus et du projet libre de Byte-Code JAVA, peut donc facilement créer des applications IPHONE et SMARTPHONE.

Merci de défendre DELPHI. Seulement, à ce que j'en ai compris, il ne s'agit plus de Pascal Objet. Il s'agit donc d'expliquer l'intérêt de cette nouvelle homogénéisation que j'appelle "Nouveau langage". Quel est l'objectif de cet Esperanto du Pascal ?

Quelle perte de temps et de moyen que la perte de services publics efficaces...

[ALWEBER]

...
Seulement, à ce que j'en ai compris, il ne s'agit plus de Pascal Objet. Il s'agit donc d'expliquer l'intérêt de cette nouvelle homogénéisation que j'appelle "Nouveau langage". Quel est l'objectif de cet Esperanto du Pascal ?
...

J'ai du mal m'exprimer. Mille excuses. Au contraire tout cela est écrit dans le plus pur respect du langage Object Pascal. Voici un extrait du code ayant servi à la réalisation du tableau de points du tore ;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
 
  procedure AjoutArLignes(i1a, i1b: integer);
  begin
    if i1a = i1b then
      exit;
    ArLignes[iLigne] := Point(min(i1a, i1b), max(i1a, i1b));
    iLigne := iLigne + 1;
  end;
 
 
begin
  Inherited Create(AOwner);
  Rotule1 := TDummy.Create(self);
  Rotule1.Parent := ViewportActif;
 
  Rotule2 := TDummy.Create(Rotule1);
  Rotule2.Parent := Rotule1;
  Rotule2.Position.Point := Point3D(10, 0, 0);
  Rotule2.RotationAngle.X := 90;
 
  Rotule3 := TDummy.Create(Rotule2);
  Rotule3.Parent := Rotule2;
  Rotule3.Position.Point := Point3D(2, 0, 0);
 
  Nb1 := 36;
  Nb2 := 12; // section
  setLength(ArPoints, Nb1 * Nb2);
  setLength(ArLignes, Nb1 * Nb2 * 3);
  iPoint := 0;
  iLigne := 0;
  for i1 := 0 to Nb1 - 1 do
  begin
    Rotule1.RotationAngle.z := Rotule1.RotationAngle.z + (360 div Nb1);
    for i2 := 0 to Nb2 - 1 do
    begin
      Rotule2.RotationAngle.z := Rotule2.RotationAngle.z + (360 div Nb2);
      ArPoints[iPoint] := Rotule3.AbsolutePosition;
      if i2 < Nb2 - 1 then
        AjoutArLignes(iPoint, iPoint + 1)
      else
        AjoutArLignes(iPoint, (iPoint - Nb2) + 1);
      iPoint := iPoint + 1;
    end;
  end;

[skrink_skrink]

adresser nativement IOS et Android )

Développer Nativement Android est un contre sens! Ce n'est pas Android mais Android(linux) et un processeur donné!
Bref exactement l'inverse de la philosophie voulu par Google avec Android!

Autant utiliser Windev Mobile, lui il utilise vraiment Android Application Framework!

[sergio_is_back]

Développer Nativement Android est un contre sens! Ce n'est pas Android mais Android(linux) et un processeur donné!
Bref exactement l'inverse de la philosophie voulu par Google avec Android!

et un processeur donné! => C'est toujours des processeurs ARM ton code fonctionnera donc
sur tous les appareils, j'ai essayé DELPHI XE7 et DELPHI XE8, j'ai pu le vérifier.... Mais pour l'instant
je n'y ai pas encore trouvé d'avantage certain ou d'application pour laquelle ce serait mieux
qu'Android studio ou Eclipse

Mais dans l'avenir je ne sait pas....

[SergioMaster]

La VCL de DELPHI XE5, forcément inspirée elle aussi de Lazarus et du projet libre de Byte-Code JAVA

mais d'où vient Lazarus ? de Delphi 7 , je ne crois pas que la VCL XE5 qui n'a que très peu changé se soit inspiré de Lazarus

Seulement, à ce que j'en ai compris, il ne s'agit plus de Pascal Objet.

encore une fois, c'est confus. Pour moi : un composant est un Objet visuel ou non, codé en Pascal, la VCL (ensemble de bibliothèques) contient aussi d'autres parties de code programmés généralement en Pascal et s'appuyant sur la programmation dite objet (héritages, propriétés, méthodes ...) .
Si vous voulez parler de Firemonkey, la technique est encore plus orientée objet dans le sens ou un composant peut être le parent d'autres composants (visuels ou non) et donc pas seulement d'une forme (comme la VCL ou la LCL ou ...) .
pour continuer sur cette lancée les Livebindings (autre terme cité) s'appuie sur les RTTI(s) soit donc sur une approche objet une fois de plus.

Non, franchement, je comprends de moins en moins vos interventions sur ce qui est au départ une simple information (statistique donc à prendre avec les pincettes qui s'imposent) tendant à indiquer que les programmeurs Pascal sont (à nouveau) demandés (ce qui regonfle nos égos ).

Je jette ici quelques réflexions
-Certes Delphi s'écarte ou a fait évoluer le langage pascal ? est-ce encore du Pascal ou un Pascal Delphi ?

-Ne confondons pas un outil RAD (ou DRA pour plaire à M. Toubon) avec le langage (ce qui est de plus en plus fréquent) et cet outil avec des techniques de programmation.

-Pascal accepte la programmation objet (fut un temps où ce n'était pas le cas car le mot même était inconnu). Pascal a évolué (et donc ne serait pas si mort que ça ) permettant ce type de programmation , on pourrait aussi dire "Pascal est mort vive Pascal Objet" ce n'est pour moi qu'un problème de formulation.

[Mouke]

Pour moi qui ait été formé il y a quelques années sur C++ Builder avec VCL, ça peut être intéressant si ça atteint la France.

Au final l'environnement et le framework me sont familiers et ça serait l'occasion d'apprendre un langage qui ne descend pas du C.

Ca peut être sympathique.

[sergio_is_back]

Par ailleurs si Pascal a une syntaxe qui met en évidence les structures de contrôle, il a aussi des travers qui nuisent à la lisibilité, par exemple le fait de déclarer les variables en en-tête de la fonction plutôt qu'au plus près de leur utilisation. Un choix qui se justifiait quand la pile d'appels était de 1024 octets mais qui va à l'encontre des bonnes pratiques reconnues aujourd'hui.

Non cela se justifie par la méthode compilation du pascal (en une seule passe) et donc effectivement les variables doivent êtres impérativement déclarées en début de fonction, tout comme
les labels (le goto c'est pas sale même si c'est pas beau), les constantes, etc...

Cela ne gêne rien et évite bien des erreurs, combien de fois j'ai vu dix la même variable redéclarée en C++ alors qu'elle est déjà déclarée plus haut dans le code, cela impose une plus grande rigueur.
Il faut s'efforcer de bien factoriser son code afin de faire des fonctions/procedures courtes et efficaces. Un peu comme dans la philosophie Linux => Chaque fonction/procedure ne fait qu'une seule chose
et le fait bien

[matthius]

Il y a une incompréhension sur le sens du mot beauté dans notre société.
Beau ne veut pas dire joli. Beau signifie qu'il y a au moins une notion éternité. Quand on défend le beau d'un langage, il s'agit de montrer ce qui le fera éternel.

Beaucoup de langages se promeuvent jolis et se disent beaux, sans que je n'envisage même pas qu'ils puissent commencer à être diffusés, parce qu'il s'agit justement de nouveaux langages.

Dans ce cas je devrais défendre les améliorations du Pascal Objet de DELPHI. Je montre qu'il s'agit de respecter la démarche pour le langage Free Pascal : La recherche de l'utile.

On me dit que les applications DELPHI 7 c'est du vieux. Ma réponse est que ce sont les plus faciles à migrer vers Lazarus Free Pascal, l'outil DRA multi-plates-formes, notamment avec Extended pour Lazarus et Dephi XE5 mon savoir-faire libre. On me dira que Lazarus pour Android c'est moins bien que Delphi. Ma réponse est que les Smartphones et les Iphones sont insécurisés depuis longtemps, ce qui n'empêche pas d'utiliser Delphi ni Lazarus.

On me dira que Extended est en GPL. Ma réponse est que le problème des logiciels privatifs est qu'ils s'autodétruisent, faisant place à des logiciels privatifs plus simples. Pourquoi ? Parce que beaucoup d'éditeurs ne comprennent pas qu'il s'agit d'être utile au client, pas de signer des contrats monétaires. Je ne tiens pas à citer certains éditeurs. Beaucoup coulent ou ont coulés. Je crois au service du logiciel et aux petits éditeurs donc. Plus un logiciel libre est utile plus il est téléchargé. Les logiciels privatifs changent de logique sans que le client puisse faire quoi que ce soit ni même le savoir à temps. C'est la cause essentielle de l'essor du logiciel libre.

Un porteur de projets disait "Des entreprises dépensent 100 000 € pour un type de logiciel que je vois gratuit." J'ai refusé d'améliorer un site web de gestion de bibliothèque fait en PHP par un ex de SSII. Selon l'économie de travail, je me suis fait un ami, éloigné certes, en lui parlant de PMB. Il va l'installer et était dégoûté de la démarche précédente. Il fallait faire comprendre que PMB était lourd parce que utilisé par des bibliothèques. Beaucoup de SSII et d'éditeurs doivent alors cacher ce genre d'outils. C'est le cas. Vive www.framasoft.net et son Agora.

Il faut cependant savoir que la fiche framasoft sur mon logiciel libre Ancestromania n'est toujours pas affichée je crois. La dernière remarque que j'ai eu sur Ancestromania était qu'il fonctionnait mal sous Windows 8, moins bien sur les très vieux ordinateurs à déterminer, bien sur le reste semble-t-il. Il faut savoir que je constate qu'on ne me recontacte plus une fois satisfait, ce qui me pose problème.

Pour moi, il y a effectivement une recherche de simplicité à avoir, ce que je ne retrouve aucunement chez beaucoup d'informaticiens qui expliquent leur langage ou outil. Ma problématique est de trouver les moyens d'expliquer mon langage de DRA, ce qui nécessite de comprendre l'économie de travail, la puissance de l'association avec le domaine public, la création de richesses réelles, sachant que le logiciel est du virtuel.

[Paul TOTH]

J'ai lu un peu en diagonale ce fil, voici ce qu'il m'inspire.

DonQuiche, entre autre, ne connais pas Delphi et critique le langage Pascal sur des critères non énoncés en le reléguant à un passé dépassé.

C'est une démarche que l'on trouve souvent chez les adaptes d'autres langages, pas toujours nouveaux d'ailleurs, mais qui ont généralement - je ne sais pas si c'est le cas de DonQuiche en particulier - le particularité d'avoir une expérience limitée. Et je précise de suite que cette "limite" n'est pas d'un point de vue compétence, de complexité ou d'importance des projets, mais c'est un point de vue à travers une lorgnette qui focalise sur leur domaine de compétence pour lequel ils sont convaincu que Delphi c'est de la merde.

La question n'est pas de savoir si Delphi est un bon produit, mais de savoir s'il répond à votre besoin.

Si mon besoin c'est, par exemple, de faire un petit site web facile à maintenir, que je puisse installer sans peine chez OVH et qui puisse être modifié sous Notepad++ via mon notebook quand je suis en vacances à la mer...je dirais qu'il est préférable d'utiliser PHP ou tout autre langage de script orienté Web. Et là je peux dire que Delphi est une usine à gaz immonde pour créer mon petit site web.

Maintenant, si j'ai un projet lourd, qui implique des traitements un peu plus complexe qu'un formulaire web, qui doit tourner sur Windows, Mac, iPhone, Android, avec des mises à jour en temps réel et des contraintes d'IU qui rend la chose complexe sous HTML5, qu'il me faut des WebServices ou de la WebAPI REST...Delphi est tout à fait capable de le gérer alors que PHP sera considéré comme une merde inutilisable.

Il y a aussi la notion de culture informatique, les développeurs formés sous Java qui ont un cerveau qui ne sait plus ce que c'est que la programmation en dehors de l'objet ou la gestion mémoire vont trouver le langage Delphi complètement absurde et en contradiction avec tous les principes élémentaires de la programmation qu'ils connaissent depuis tout petit.

Les accros du C en ligne de commande vont vomir sur un IDE WYSIWYG haut en couleur qui permet de ne jamais mettre les mains dans les "DFM" qui ont l’outrecuidance de ne pas utiliser le format XML pour sérialiser les fiches de l'application.

Bref, Delphi, ce n'est pas Rubby, ce n'est pas .Net, ce n'est pas Java et c'est pour cela qu'il est intéressant, car il a son caractère propre et qui sait l'utiliser va très loin. Il n'est pas pour autant la réponse ultime et l'outil incontournable vu que cela n'existe tout simplement pas.

[DonQuiche]

Sais tu comment est implémentée l'instruction yield en C# ? Ne s'appuie t'elle pas sur une vaste et complexe bibliothèque ? Dès qu'on touche aux threads on peut rencontrer des bogues difficiles à comprendre. Comment peux tu dire que "ce bricolage lent et bogué" sans l'avoir testé ?

En C# "yield return" fait l'objet d'une simple transformation syntaxique à la compilation et aucune bibliothèque n'est nécessaire. Tout se déroule sur le même thread, ça n'a rien à voir avec la concurrence, c'est un simple moyen d'écrire des itérateurs.

Quant au reste je m'en suis expliqué mais je détaille : je sais que les green threads sont impropres pour les itérateurs parce que chaque changement de contexte va requérir des centaines de cycles CPU, ce qui est prohibitif. Alors qu'avec un support natif par un bon compilateur le coût devrait être strictement nul avec dans la majorité des cas. En revanche je retire ce que j'ai dit sur les bogues : les raisons que j'avais données (problèmes avec le TLS) ne tiennent pas puisque ces green threads vont être exécutés sur le thread système parent.

Tu reproches également la non portabilité : c'est vrai d'ailleurs l'auteur l'indique car il s'appuie sur les fibres Windows. Mais si on utilise des threads natifs la portabilité en prendra aussi un coup non? Comme tu fais du C#, sa portabilité est un peu limitée par rapport à celle de Java, non ?

Tu peux utiliser "yield return" en c# sur Windows, Linux, Android, iOS, OSX, X1, X360, PS3, PS4 et bien d'autres.

Cela dit je ne suis pas là pour défendre c#, donc je m'en cogne un peu.

Pour info, Delphi XE8 dispose en standard de la méthode yield (mais je ne l'ai pas mentionnée car je ne sais pas si c'est valable pour tous les compilateurs Pascal) et c'est comme pour Java pour les threads (classes TThread et TMonitor par exemple).

Non, Thread.Yield n'a rien à voir avec "yield return," ce sont deux choses complètement différentes. Thread.yield n'est qu'un mapping d'une fonction du système d'exploitation qui rend la main du thread courant pour laisser le temps à d'autres de s'exécuter.

Je ne dis pas que Pascal a résolu le problème, j'essaye juste de montrer qu'il existe des moyens en Pascal d'y répondre également.

Faisable et valable sont deux choses différentes : si personne n'utilise ces soi-disant solutions, il y a une bonne raison. A mon humble avis cela revient à nier le problème pour tenter de gagner un débat.

Donc non votre biblio inconnue pour yield offre des performances médiocres et personne ne l'utilise, vos lambdas ont une syntaxe tellement malcommode que personne ne les utilise pour des continuations de liste là où c'est un bonheur dans d'autres langages, et vous avez une biblio amateure à la qualité inconnue pour du GPGPU mais je ne vois personne utiliser Pascal pour du GPGPU.

Et pour Windev contre Pascal, je me suis pas prononcé, je n'ai fait qu'émettre une hypothèse.

Je ne cherche pas à savoir que tel langage est meilleur qu'un autre : c'est un débat stérile et chacun à ses forces et faiblesses.

Ce n'est pas un débat stérile puisque les conséquences du choix d'un langage se chiffrent en milliards d'euros sur l'ensemble des seules entreprises françaises.

Un point qui n'est pas abordé dans cette discussion : les pré-requis nécessaires aux binaires générés. Un exécutable compilé en Pascal (mais ce n'est pas le seul) fonctionne directement sur une machine (il n'y a pas besoin de runtime ou de framework particulier en plus de l'OS comme c'est le cas pour Java ou C#).

Et d'autres langages modernes ne demandent pas de runtime.

Non cela se justifie par la méthode compilation du pascal (en une seule passe) et donc effectivement les variables doivent êtres impérativement déclarées en début de fonction, tout comme
les labels (le goto c'est pas sale même si c'est pas beau), les constantes, etc...

Quoi, vous non plus vous n'avez pas corrigé ce vieux modèle de compilation prévu pour des ordinateurs ayant trop peu de mémoire pour faire tenir le code et ses représentations en mémoire ?! Vous vous cognez encore des déclarations forward et compagnie ?
Je retire ce que j'ai dit : utiliser Pascal pour l'enseignement serait criminel !

Et, non, ça n'a rien à voir : pour preuve le C/C++ utilisent aussi une compilation en une passe. Pour une variable il suffit que la déclaration soit faîte avant son usage pour que le compilateur en connaisse le type à ce moment. Quant au label il suffit de vérifier à la fin de la méthode qu'on a bien rencontré la définition.

Quant aux redéfinitions en C/C++, là aussi ça n'a rien à voir, c'est en fait un mauvais choix délibéré de ce langage. Aucun rapport avec le modèle de compilation.

Pour l'aspect bibliothèques disponibles, l'argument des très nombreuses productions (en C++ surtout) ne tient qu'à moitié : sans compter les productions propres dont certaines sont très performantes (TMS, TRichView, EnVision, Esbpcs...) , des wrappers existent pratiquement pour tout ce qu'on veut. Je ne connais pas une application qu'on ne peut pas écrire avec Delphi. En revanche, je le déconseillerais pour du non applicatif, c'est sûr.

Je ne suis déjà pas satisfait des wrappers dispos dans les langages avec de fortes communautés, je doute donc que la situation soit si idyllique en Pascal.

La question n'est pas de savoir si Delphi est un bon produit, mais de savoir s'il répond à votre besoin.

Non, je l'ai déjà dit : la question est de savoir s'il offre le meilleur rapport qualité-prix.

[tourlourou]

La question n'est pas de savoir si Delphi est un bon produit, mais de savoir s'il répond à votre besoin.

Non, je l'ai déjà dit : la question est de savoir s'il offre le meilleur rapport qualité-prix.

Je ne vois pas de contradiction. Si le besoin est centré sur le rapport qualité-prix pour untel, le besoin que cherchera à satisfaire tel autre - tenant compte de son histoire, de ses contraintes - pourra être différent.

[sergio_is_back]

Quoi, vous non plus vous n'avez pas corrigé ce vieux modèle de compilation prévu pour des ordinateurs ayant trop peu de mémoire pour faire tenir le code et ses représentations en mémoire ?! Vous vous cognez encore des déclarations forward et compagnie ?
Je retire ce que j'ai dit : utiliser Pascal pour l'enseignement serait criminel !

Quant aux redéfinitions en C/C++, là aussi ça n'a rien à voir, c'est en fait un mauvais choix délibéré de ce langage. Aucun rapport avec le modèle de compilation.

Ce "vieux" modèle reste pourtant implémenté dans le compilateur Pascal et il a fait ses preuves ! (même si il peu avoir des faiblesses)
Pascal a été pensé pour être déclaratif et typé point, c'est peut être une faiblesse mais aussi une force dans beaucoup, on ne mélange pas
les torchons avec les serviettes et les vaches sont bien gardées !

Vous vous cognez encore des déclarations forward et compagnie

Quand c'est nécessaire oui et pas c'est pas propre au Pascal au passage...

Je retire ce que j'ai dit : utiliser Pascal pour l'enseignement serait criminel !

Faux cela donne de bonnes habitudes, je vois passer plein de stagiaires qui ont débuté qui en C++, qui en Php : ils écrivent leur code n'importe comment, une chatte n'y retrouve pas ces petits, c'est in-maintenable par la suite
sans parler des fuites mémoire en C++ (et des mauvaises désallocation de pointeurs)

Je ne suis déjà pas satisfait des wrappers dispos dans les langages avec de fortes communautés, je doute donc que la situation soit si idyllique en Pascal.

Nan y'a pas situation idyllique en Pascal, pas plus qu'en C, en C++, en WinDev, en VB, en C#, etc... surtout lorsque l'on est obligé de mixer plusieurs technos sur un projet

Non, je l'ai déjà dit : la question est de savoir s'il offre le meilleur rapport qualité-prix.

Là dessus on pourrait y passer des heures : Le choix de tel ou tel langage dépend du projet, du temps que vous avez pour le réaliser, des désirs du client (qui n'est pas souvent
l'utilisateur final), de l'utilisateur final justement, des contraintes matérielles (les entreprises nous imposent leur plateforme existante, matériel embarqué ou non, périphériques
éxotiques, etc... )... et enfin de la marge que vous pensez réaliser (souvent à tord au début) car c'est le nerf de la guerre.

De mon expérience il n'y a jamais de solution "miraculeuse" mais comme le disait gvasseur58 plus haut Delphi/Pascal Objet convient pour une
grosse majorité de mes projets (surtout en industrie) et moi aussi "Je ne connais pas une application qu'on ne peut pas écrire avec Delphi." même si il faut savoir parfois
raison garder et se dire qu'il n'est pas le mieux adapté dans certaines circonstances....

[DonQuiche]

Je ne vois pas de contradiction. Si le besoin est centré sur le rapport qualité-prix pour untel, le besoin que cherchera à satisfaire tel autre - tenant compte de son histoire, de ses contraintes - pourra être différent.

Connais-tu beaucoup de cas de figure où le prix/temps ne compte pas en supposant qu'il est possible d'obtenir le même résultat ?
Si cela ne comptait pas, le cheval serait toujours vu comme une alternative à la voiture.

Quand c'est nécessaire oui et pas c'est pas propre au Pascal au passage...

Effectivement, c'est propre à tous les vieux langages puisque cela s'expliquait par le fait qu'à l'époque la mémoire se comptait en kilooctets et qu'on n'avait pas le choix. Aucun langage moderne correct (écrit par des gens qui savent ce qu'ils font) n'a fait un tel choix bien sûr, ça n'a que des inconvénients.

Pascal a été pensé pour être déclaratif et typé point, c'est peut être une faiblesse mais aussi une force dans beaucoup, on ne mélange pas les torchons avec les serviettes et les vaches sont bien gardées !

En quoi déclarer ses variables en haut de la méthode plutôt qu'au plus près de leur usage comme le recommandent tous les auteurs modernes, aurait quoi que ce soit à voir avec le fait d'être un langage typé ?

Quant au fait d'être un langage déclaratif, non puisque par définition ce terme s'applique aux paradigmes non-impératifs (certaines formes de frp, programmation par contraintes, grammaires, etc).

Faux cela donne de bonnes habitudes, je vois passer plein de stagiaires qui ont débuté qui en C++, qui en Php : ils écrivent leur code n'importe comment, une chatte n'y retrouve pas ces petits, c'est in-maintenable par la suite sans parler des fuites mémoire en C++ (et des mauvaises désallocation de pointeurs)

Les programmeurs Pascal sont les übermenschen du code en somme ?

Mais il est intéressant de noter que tout ce qu'il faut pour conduire les programmeurs à ne plus causer de bogues et à produire du code propre, c'est les obliger à placer leurs variables en haut de la méthode. Qui eût cru qu'une astuce si simple pouvait produire de si formidables résultats ?!

C'est surprenant parce que je croyais préférable de placer ses fonctions dans un ordre optimisé pour la lecture par un être humain (du plus haut niveau vers les détails de mise en oeuvre par exemple) plutôt que pour satisfaire une technique de compilation archaïque. Non ?

[Paul TOTH]

Connais-tu beaucoup de cas de figure où le prix/temps ne compte pas en supposant qu'il est possible d'obtenir le même résultat ?
Si cela ne comptait pas, le cheval serait toujours vu comme une alternative à la voiture.

qu'il compte c'est une chose, mais que ce soit un critère déterminant en est une autre. Tous mes clients sont ravis de me payer très cher pour des solutions qui fonctionnent assurément...ils sont passé par des solutions rapides et pas chers et en ont fait les frais.