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.
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.
Merci à toi !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
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 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.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.
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.
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.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++...).
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.
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.Bon, je ne sais toujours pas ce que tu pratiques comme langage en ce moment. Je pencherais pour Java ou C#, je me trompe ?
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).
Partager