Discussion :

[crodilus]

Je n'ai du comprendre que 25 % de la discussion mais au moins ça m'aura donné l'envie de tester Lazarus et le Pascal Objet ! Parole d'un développeur C# qui pour l'instant s'occupe plus à écrire du RPG et du CL

[free07]

Je n'ai du comprendre que 25 % de la discussion mais au moins ça m'aura donné l'envie de tester Lazarus et le Pascal Objet ! Parole d'un développeur C# qui pour l'instant s'occupe plus à écrire du RPG et du CL

[matthius]

J'indiquais que j'utilisais l'économie pour expliquer l'utilisation de mon langage.
Je vais vous indiquer que la technique informatique, pas la technologie informatique, comme on nous a fait croire, consiste à gérer des informations en créant des systèmes. Jusque là on ne voit pas l'économie de l'informatique. C'est là le problème : L'informatique, comme tous les métiers, est utile à partir du moment où elle permet le développement de la société humaine. On appelle ces derniers termes l'économie.

Là viennent les décroissants. L'histoire à la fois de la vie et de notre société a prouvé un développement à la fois de la vie et de l'humain. Pour expliquer cette incompréhension, il faut savoir qu'avant on parlait de malthusianisme. L'incompréhension sur la décroissance n'est qu'historique et sémantique.

On me dira que l'économie actuelle décroît. Là je ne suis pas d'accord. La finance croît. Par contre la finance n'est pas économique effectivement. On parle là d'économie monétaire. L'économie monétaire c'est la croissance financière.

La relation entre écologie et économie est proche. L'écologie c'est le développement de la nature. L'économie, qu'il faut expliquer maintenant comme physique, c'est le développement de la société humaine. La relation entre les deux c'est par exemple de dire que les barrages servent à l'agriculture, pas qu'aux agriculteurs.

La société peut donc se développer. Comment le fait-elle ? Par la technologie. Michel Serres indique comme moi que l'informatique n'est pas une technologie. Michel Serres dit qu'il n'y a pas de logique industrielle derrière l'informatique. La production d'ordinateur est une industrie. Seulement gérer des informations et des systèmes fut classé comme service. On m'a appris que l'informatique sert à optimiser les industries et la science. Je m'interroge sur la partie scientifique de l'informatique, à savoir que la recherche quantique n'a pas eu besoin de l'informatique pour être créée. Maintenant on apprend à la nouvelle génération que les services sont des industries. C'est là une dérive financière. La finance dit même qu'elle est industrie.

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.

Vision économique : Cela est-il réellement utile ?

En effet, cela va demander à diversifier son savoir-faire dans différents langages. Il y a là pire même, à savoir qu'il s'agit de disposer de beaucoup de moyens pour être simplement à la mode d'une novlangue, qui repose sur la simplification d'itérateurs. On veut donc simplifier en complexifiant.
En tant que développeur avec EDI de DRA, j'évite au maximum d'utiliser l'itération, plutôt les données gérées par du langage SQL. Pour ceux qui me disent que les itérateurs peuvent être plus rapides, je dis que c'est possible. Seulement ce n'est pas ce que j'ai constaté.
Pour ceux qui disent de ne pas utiliser le langage SQL, je dis que pour le Client/Serveur, qu'on appelle maintenant application mobiles, je n'ai rien vu de plus rapide. Cela peut étonner certains. C'est ce que je constate. Le problème là est surtout qu'on m'avait appris à décentraliser l'informatique, pas à l'envoyer aux États-Unis.
Par contre le 3 tiers, qu'il soit web ou pas, est pour moi forcément plus lent, pour la simple raison qu'il y a un intermédiaire supplémentaire.
L'intermédiaire, au niveau économique, sert à créer la trafic, ce qu'explique Henry Charles Carey. Pour empêcher cela, il y a le train et le développement industriel, en créant de l'argent pour cela, après avoir détruit l'argent spéculatif, ce qui est possible en coupant la finance des banques de dépôt.

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

Là il y a une méconnaissance totale de l'économie, du commerce, et une valorisation du trafic.
Le rapport qualité/prix est effectivement important en informatique. Un service repose sur les industries et doit comprendre à sa manière, pas le rapport qualité/prix exactement, mais comment il peut être utile aux industries. Quand un éditeur en informatique est peu connu le rapport/qualité prix montre sa capacité à être bénéfique pour les industries. Le problème à ce moment là c'est de se demander si on parle de qualité. Je dirais qu'il s'agit de placement commercial. En effet, un éditeur avec un outil mal fait s'en rendra compte très rapidement. Il baissera les prix. Par contre un éditeur qui aura un outil au top le vendra très cher. Le rapport/qualité prix est important en informatique mais pas pratiqué dans le privatif.

Le principe du rapport/qualité prix existe en informatique mais il est le mieux constaté avec les logiciels libres. Les logiciels propriétaires vont d'ailleurs utiliser les normes qualités pour augmenter les prix. Par contre une entreprise paiera cher un mauvais choix de logiciels. On se rend compte que c'est Linux l'environnement le plus sûr, techniquement bien sûr. On pourra effectivement dire que beaucoup d'entreprises françaises sous Windows n'ont pas été attaquées. En France ce sont surtout les PME qui ont Linux. Il s'agit donc de comprendre qu'elle ne sont pas idiotes.

J'ai eu du mal à expliquer à un défenseur de Windows qu'un environnement avec 400 virus créés par jour n'est pas fiable. Je comprends pourquoi. Le pare-feu hardware ça n'a jamais existé. Il s'agit d'ordinateur pare-feu. Avec Linux on peut se protéger d'Internet sans avoir de pare-feu supplémentaire. On peut se protéger d'une injection sur sa box en gérant soi-même sa box, ou bien en utilisant Linux en ne se connectant à Internet qu'après avoir activé le pare-feu. Sur Windows on dit qu'il s'agit de paramétrer le pare-feu.

Premier bilan : Un environnement qui peut être gratuit est à la fois plus simple et plus sûr. Le Rapport/Qualité c'est Linux ou tout logiciel libre utile. Le problème pour moi est que je pense que le meilleur système d'exploitation pour particuliers débutants est EMMABUNTU, de Emmaüs, lorsque le particulier veut s'enrichir ou s'augmenter comme le dit Michel Serres. À Emmaüs il y a aussi les machines à écrire. Ce sont des jouets créatifs pour moi, qui permettent de ne pas rendre idiot l'enfant avant d'utiliser l'ordinateur. En effet, la machine à écrire permet de comprendre l'importance de l'anticipation avec une structuration engageant vers l'architecture. Tout système électronique s'inspirant de l'humain ou d'une partie de l'humain peut être critiqué de la même manière. En effet, savoir être autonome est une première demande des entreprises.

Seulement les 180 millions d'euros placés en informatiques cette année vont nuire à l'économie. Ça n'est pas facile à comprendre pour les informaticiens. Je constate que l'outil informatique est intéressant effectivement. Seulement le fait qu'il soit intégré au PIB est un problème. Pour le technique l'explication est simple. Pourquoi refaire ce qui se copie-colle ? Pour la partie économique il y a encore plus simple. Un logiciel ne se mange pas. Un ordinateur ne fait pas la cuisine.

Ainsi on peut parler des robots. Pour moi c'est une technologie. En effet les robots mobiles et sociaux pourront remplacer tout ce qui est social. Je comprends que beaucoup prennent peur de ce que je viens de dire. C'est en effet le discours inverse qui est dit, de trouver un travail, pas de flâner. Là je peux vous assurez qu'il y a mieux que flâner. Cela s'appelle créer des richesses, pour soi et les autres. C'est comme cela que beaucoup comprennent le commerce. C'est la définition économique du commerce. Le commerce consiste effectivement à créer des richesses, pas forcément des produits effectivement, pour être rémunéré de cela par une monnaie publique, citoyenne donc.

Certains pourront me dire que ça n'est pas constaté. Seulement toute organisation est de raison. Toute organisation finira par se retourner vers ceux qui veulent développer la société par la création de richesses. Le problème est alors de les rémunérer. C'est là effectivement qu'il y a un problème. Les ouvriers constatent ce problème. Vous pourrez me dire que ça permet de décrédibiliser. C'est ce qu'on nous répète. Là question c'est "Pendant combien de temps allez-vous croire cela ?" Il est constaté que les premiers à décrédibiliser sont ceux qui ne connaissent que ça.

Le problème n'est pas de trouver un travail pour avoir un salaire et une maison, c'est de développer la création de richesses par l'association. On me dit souvent qu'il faut bien vivre, travailler pour vivre. Je réponds très facilement à ce genre de propos en disant que ma passion est de permettre de créer des richesses. Certains seront alors jaloux et diront que c'est pas du jeu. Je leur dit alors que notre capacité créative se développe en comprenant la société, pas en faisant le robot. Par contre je suis d'accord que c'est le confort qui me permet de faire cela. Seulement j'ai compris l'intérêt du confort : la création de richesses pour soi et les autres. D'autres réfléchiront à l'envers. Ceux qui diront que c'est le travail qui permet le confort devront m'expliquer ce qu'ils font de ce qu'ils possèdent. Ce que je possède c'est la possibilité de créer des richesses. Quelqu'un qui possède trop se croit dans une maison hantée. Cela veut dire que ce qu'il possède n'est pas une richesse, parce qu'il ne sait pas l'utiliser.

Dans ce cas tous ceux qui peuvent créer des richesses et n'ont pas d'argent peuvent s'offusquer. Je leur dit que des banques comme PSA Banque ou toute banque qui accepte les interdits bancaires permet à ces personnes de créer des richesses, pour recréer du commerce et une rémunération monétaire. Cela nécessite cependant de mettre la finance au pas pour pouvoir continuer.

Vous remarquerez qu'on peut éviter toute notion monétaire en connaissant l'économie, par le simple fait que l'économie peut être expliquée sans indicateur monétaire, par une connaissance des Principes de la Science Sociale. Pourquoi ? Parce qu'on peut faire dire n'importe quoi aux chiffres, pour la simple raison que quiconque comprend les mots plus facilement.

[SergioMaster]

Je n'ai du comprendre que 25 % de la discussion mais au moins ça m'aura donné l'envie de tester Lazarus et le Pascal Objet ! Parole d'un développeur C# qui pour l'instant s'occupe plus à écrire du RPG et du CL

RPG est donc toujours vivant ça fait un bail que je n'en avais plus entendu parler !
parole d'un converti Delphi ou plutôt RAD

[SergioMaster]

L'écologie c'est le développement de la nature.

non, en premier lieu c'est la science des habitats même si pour beaucoup le mot écologie à pris une définition plus large.
pour un chasseur borné un "écologiste" est un ami des petits oiseaux qui empêche le monde (nombriliste) de s'amuser. Certains chasseurs sont des écologistes pourtant : ils ont une science de l'habitat et essaye de maintenir/réguler ce dernier

La relation entre écologie et économie est proche

aucun rapport car le terme écologie est dans ce cas uniquement la partie "développement durable"

[DonQuiche]

...

Je m'excuse si je ne t'ai pas répondu jusque là et je ne voudrais pas paraître grossier en t'ignorant.

Malheureusement, et ce n'est pas très courtois, je dois avouer que je trouve que ton discours manque de cohérence, pars dans tous les sens et que tu manies toutes sortes de notions que tu ne maîtrises pas. Petit exemple avec ce qui suit :

En tant que développeur avec EDI de DRA, j'évite au maximum d'utiliser l'itération, plutôt les données gérées par du langage SQL.

Cette phrase est équivalente à la suivante :
"En tant que mécanicien avec clé à molette de changements de pneus, j'évite au maximum d'utiliser la parole, plutôt les données gérées par du clavier".

Il est donc difficile de te prendre au sérieux.

Pour ceux qui disent de ne pas utiliser le langage SQL, je dis que pour le Client/Serveur, qu'on appelle maintenant application mobiles, je n'ai rien vu de plus rapide. Cela peut étonner certains. C'est ce que je constate. Le problème là est surtout qu'on m'avait appris à décentraliser l'informatique, pas à l'envoyer aux États-Unis.

Un itérateur est une abstraction mince, au coût souvent nul, qui fait l'interface avec n'importe quoi : en général quelque chose de très léger (une liste ou un tableau), plus rarement quelque chose d'extrêmement lourd. En revanche SQL est une abstraction lourde (nécessitant de nombreux traitements par la SGBD), qui fait l'interface avec quelque chose de très lent et lourd (le SGBD).

On ne choisit pas un SGBD pour les performances mais parce qu'il offre une solution pour le partage, la persistance et l'intégrité des données. Je comprends que tu es convaincu d'avoir observé le contraire mais soit les lois de la physique et des mathématiques sont différentes par chez toi, soit tu as mal compris ce que tu avais devant les yeux.

Par contre le 3 tiers, qu'il soit web ou pas, est pour moi forcément plus lent, pour la simple raison qu'il y a un intermédiaire supplémentaire.

Oui, sauf qu'en général ce coût n'est pas significatif (on parle de nanosecondes en plus sur un traitement de plusieurs micro- ou milisecondes) et cette architecture est choisie pour sa lisibilité, sa maintenabilité et son évolutivité. Ce qui est significatif.

Vision économique : Cela est-il réellement utile ?

Si j'ai bien compris ton discours (c'est difficile), tu argues que quelque soit le bénéfice apporté celui-ci est annihilé par le fait de devoir passer par des solutions propriétaires.

a) C# n 'était qu'un exemple parmi d'autres et des solutions libres ont adopté les mêmes mécanismes : Python, Rust ou Java par exemple.
b) La grande majorité des entreprises ont une appréciation différente de la tienne de la valeur du libre, l'un de vous d'eux a donc tort. Et je ne pense pas que tu sois celui qui a raison.


PS : je me réserve le droit de répondre ou non, de ne pas m'engager dans une discussion soutenue avec toi si je le désire. Je te prie de m'en excuser.

[gbegreg]

En C# "yield return" fait l'objet d'une simple transformation syntaxique à la compilation et aucune bibliothèque n'est nécessaire.

Elle est pas mal celle là : le framework .Net doit être installé pour que le programme fonctionne non ?

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.

Pas de problème, je suis d'accord avec toi.

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

Développes tu dans le domaine des jeux vidéos ? Si oui, ça expliquerait certaines de tes positions.

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 n'ai pas dit le contraire : j'ai commencé ma phrase par "Pour info", et je dis que c'est comme en Java que ça n'est valable que pour les threads.

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.

Je ne nie pas le problème : je dis que dans mon expérience je n'ai pas ressenti le besoin d'utiliser ces solutions. Les génériques et les lambdas, je les utilise car j'en ai le besoin, mais pour le "yield return " j'avoue n'avoir jamais rencontré le besoin ou alors sans savoir je me suis débrouillé autrement.

Comme, je l'ai déjà dit et plusieurs autres personnes également, le choix de la techno se fait en fonction des besoins, de l'architecture envisagée, des compétences disponibles et des coûts. Si une entreprise dispose de compétences dans un langage et que ce langage est en capacité à répondre aux besoins utilisateurs, je ne pense pas que l'entreprise va se lancer dans une techno qu'elle ne maitrise pas (les infra seront peut être à modifier, le personnel à former, logiciels à remplacer, l'ingénierie de dev à revoir, et les délais du projet seront plus longs le temps que les équipes montent en compétences...). Le coût c'est un tout et pas seulement l'acquisition d'un produit.

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

Des preuves de ce que tu avances ? ou c'est une nouvelle hypothèse...

vous avez une biblio amateure à la qualité inconnue pour du GPGPU mais je ne vois personne utiliser Pascal pour du GPGPU.

J'ai donné un des liens renvoyés par Google c'est vrai, mais c'était pour Pascal. Parce qu'en Delphi, Firemonkey le fait (essaye la version d'évaluation de Delphi et tu auras des démos fournies avec).

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

Encore une fois, une hypothèse qu'il était facile de vérifier avant de poster : toutes les fonctionnalités que tu listes comme étant bien plus évoluées avec WinDev, on les retrouve sous Delphi et de nombreux composants ou librairies tiers existent aussi (OCR et Code Barre je connais beaucoup mieux que les threads...).

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.

J'ai déjà donné mon avis sur le côté coût, quand je dis que le débat sur le langage A est meilleur que le langage B est stérile, c'est parce qu'il n'existe pas de langage idéal pour répondre à tout. Les besoins sont très différents : un développeur de jeux vidéos n'a pas les mêmes contraintes qu'un développeur d'une application comptable, financière, de gestion... Dans les grandes entreprises tertiaires (banques, assurances...), le cobol reste encore très utilisé par exemple. Je pense que tu serais surpris du nombres de flux financiers qui passent par du cobol dans le monde chaque jour (même à partir de sites web) ! Contrairement aux idées reçues là encore le cobol évolue : il s'interface avec .Net et J2EE, on utilise Eclipse ou Visual Studio comme IDE... Je m'éloigne un peu du sujet mais c'est pour illustrer.

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

C'est ce que j'ai dit : le Pascal n'est pas le seul dans ce cas.

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

Android Studio est fait pour le développement Android : il risque d'être meilleur que Delphi pour faire de l'Android pur. Comme Xcode est certainement meilleur pour le développement IOS. Par contre, je vois un avantage avec Delphi : je change la cible dans les options de build et je génère le binaire soit pour Android, soit pour IOS. Accessoirement, je peux aussi générer une application bureau (Windows ou Mac OS X). Le constructeur d'interface graphique de Delphi est quand même pas mal et du peu que j'ai pratiqué, je trouve que FireUI en est une très bonne évolution.

[matthius]

Je m'excuse si je ne t'ai pas répondu jusque là et je ne voudrais pas paraître grossier en t'ignorant.

Tu le fais déjà par l'ensemble de tes réflexions, montrant par ailleurs qu'un logiciel pourrait te remplacer.

Cette phrase est équivalente à la suivante :
"En tant que mécanicien avec clé à molette de changements de pneus, j'évite au maximum d'utiliser la parole, plutôt les données gérées par du clavier".

Il est donc difficile de te prendre au sérieux.

On appelle cela du troll. J'appelle cela l'aboutissement du libéralisme ou comment ne rien comprendre sur quelqu'un qui essaie de te comprendre. D'autres diront l'aboutissement du troll ou comment comprendre l'intérêt de la réflexion scientifique.

Un itérateur est une abstraction mince, au coût souvent nul, qui fait l'interface avec n'importe quoi : en général quelque chose de très léger (une liste ou un tableau), plus rarement quelque chose d'extrêmement lourd. En revanche SQL est une abstraction lourde (nécessitant de nombreux traitements par la SGBD), qui fait l'interface avec quelque chose de très lent et lourd (le SGBD).

On ne choisit pas un SGBD pour les performances mais parce qu'il offre une solution pour le partage, la persistance et l'intégrité des données. Je comprends que tu es convaincu d'avoir observé le contraire mais soit les lois de la physique et des mathématiques sont différentes par chez toi, soit tu as mal compris ce que tu avais devant les yeux.

Cela va t'étonner mais il existe ce qu'on appelle les fonctions SQL. Fonction veut dire programmation. Tu es donc en train de découvrir qu'on peut programmer avec du SQL. L'itération te paraît révolutionnaire. Elle existe depuis le début de la programmation. Je la trouve très rapide en SQL pour les données effectivement.

Oui, sauf qu'en général ce coût n'est pas significatif (on parle de nanosecondes en plus sur un traitement de plusieurs micro- ou milisecondes) et cette architecture est choisie pour sa lisibilité, sa maintenabilité et son évolutivité. Ce qui est significatif.


Si j'ai bien compris ton discours (c'est difficile), tu argues que quelque soit le bénéfice apporté celui-ci est annihilé par le fait de devoir passer par des solutions propriétaires.

a) C# n 'était qu'un exemple parmi d'autres et des solutions libres ont adopté les mêmes mécanismes : Python, Rust ou Java par exemple.
b) La grande majorité des entreprises ont une appréciation différente de la tienne de la valeur du libre, l'un de vous d'eux a donc tort. Et je ne pense pas que tu sois celui qui ait raison.


PS : je me réserve le droit de répondre ou non, de ne pas m'engager dans une discussion soutenue avec toi si je le désire. Je te prie de m'en excuser.

En comparant C# à Python ou Java tu dis donc que Visual studio n'est plus du DRA. Est-ce vrai ?

Je te défie de trouver une vidéo anti-linux d'actualité mettant l'informaticien et la société humaine en valeur.

Mon explication est une proposition de compréhension économique. C'est une proposition demandant donc dialogue, pas déni.
J'ai aussi simplifé mon discours :
http://www.agoravox.tv/IMG/pdf/2015-...mie-Reelle.pdf
Je préfère le mot argumenter à arguer.

Ce document nécessite de philosopher. Je te conseille une liseuse ou de l'imprimer (il est court), afin de ne pas te sentir fatigué en le lisant.
Si tu ne le comprends pas, tu peux le faire lire à un enfant qui connaît les mots du document. Je crois qu'il pourra au moins d'expliquer un début de compréhension, ce que j'essaie de faire avec toi, que tu dénies alors pour te décrédibiliser. Dans ce cas mon dialogue avec toi aura servi à quelque chose.

Voici un document qui explique aussi l'économie pour les informaticiens :
https://archive.org/details/Libre-Economie-DRA

Je pensais avoir déjà lié ce document. Comme quoi ce sont ceux qui en savent le moins qui en disent le plus.

[gvasseur58]

Personnellement, si je devais retenir une contribution de cette discussion (d'autres étaient très intéressantes, mais celle-ci a le mérite de la synthèse), je choisirais celle de Paul Toth :

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

DonQuiche, entre autre, ne connaît 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 adeptes 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 convaincus 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.

Quitte à me répéter, je ne crois pas qu'il y ait une querelle des anciens contre les modernes, mais plutôt une propension bien humaine à défendre ce qu'on connaît, voire à combattre tout ce qui sort du champ de ce qu'on pense être le VRAI. Sinon, on s'explique mal que DonQuiche renvoie la programmation parallèle aux années 90 (voir le livre de Hodges) et soit persuadé que les programmeurs à la page (ceux qui pratiquent le C#, entre autres) sont constamment sur la brèche quand il s'agit d'intégrer de nouveaux concepts ou de nouvelles techniques (voir son affirmation dans un post précédent).
Tout cela est très excessif : un langage qui aurait su exploiter les processeurs multi-cœurs en 1990 serait venu de Mars et, comme tous les programmeurs, ceux qui pratiquent des langages apparus récemment commettent des bourdes... archaïques
Rien que ce matin, je me promène sur CodeProject et y lis un article intitulé Sometimes, we overlook the simplest things. C'est un article concernant le C# sur un site sérieux qui filtre ses publications. L'auteur nous montre qu'il est très pénalisant en termes de vitesse d'exécution du code d'employer un contrôle des exceptions. Un problème pour DonQuiche, c'est que la méthode la plus rapide (sauf en programmation linéaire pour 1000 itérations) n'est pas celle qui a raccourci le code au maximum en employant des outils du C#, mais la méthode "ancienne" qui consiste à tester par un if avant d'exécuter une/des instruction(s) Second problème pour DonQuiche : la démonstration fournie par l'auteur est un exemple d'utilisation des exceptions à proscrire . Une fois l'erreur capturée, l'auteur donne une valeur arbitraire à une variable en masquant l'exception, sans d'ailleurs se préoccuper d'une éventuelle exception dans son bloc, ce qui conduirait à une autre variable à la valeur indéterminée. Je ne suis pas en train de dire que le C# est mauvais (d'autant plus que c'est la même personne qui a conçu le Pascal Objet et le C# ), mais qu'il sera toujours ce que le programmeur en fera. Celui qui programme un langage n'est pas plus infaillible et croit parfois résoudre un problème réel en en créant une ribambelle en aval (j'en reviens aux compteurs de références bien présents dans Pascal Objet via les interfaces depuis une bonne décennie). [Je précise que si le C# est cité, on peut le remplacer par n'importe quel langage, y compris le Pascal, bien sûr.]

[Roland Chastain]

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.

Apparemment vous avez oublié comment se terminait votre premier message, alors je vous le cite :

Mais bon... Si ça vous amuse d'écrire toujours les mêmes bouts de code qu'un compilateur pourrait écrire à votre place...

Et voici, pour mémoire encore, un autre échantillon de votre courtoisie :

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

Alors, de grâce, arrêtez votre cinéma !

[DonQuiche]

Quitte à me répéter, je ne crois pas qu'il y ait une querelle des anciens contre les modernes, mais plutôt une propension bien humaine à défendre ce qu'on connaît, voire à combattre tout ce qui sort du champ de ce qu'on pense être le VRAI.

Qui ici a déjà fait de la programmation procédurale, impérative, objet, logique, par contrainte, fonctionnelle, par acteurs, et manipulé des grammaires ? Qui ici a au moins étrenné un nouveau langage depuis le début de l'année ? Davantage ?

Je suis au contraire toujours à l'affût de nouveaux paradigmes. Tout le monde ici peut-il en dire autant ? Certains ne se sont-ils pas simplement habitués à manipuler le même langage depuis trop longtemps ?

Ne tente pas de me faire passer pour le conservateur dans l'histoire.

Sinon, on s'explique mal que DonQuiche renvoie la programmation parallèle aux années 90 (voir le livre de Hodges)

MPI et OpenMP ont en effet été introduits dans les 90's et sonnaient l'âge de la maturité pour ces concepts.

Je ne dis évidemment pas que ces concepts sont anachroniques, bien sûr que non, simplement qu'ils font partie d'une fonctionnalité plus ou moins standard, bienvenue (*) mais loin d'être suffisante ou moderne à notre époque. Aujourd'hui on attend plutôt des modèles à base d'acteurs, on attend que le compilateur soit en mesure de garantir que tel modèle est correct (et s'il ne peut pas le garantor, de le signaler comme une erreur), qu'il prévienne les partages accidentels de mémoire, etc. Bref, des fonctionnalités qui répondent vraiment au besoin : permettre à n'importe quel programmeur d'exploiter systématiquement la puissance du parallélisme, qu'il soit un expert qui fera pourtant des erreurs, ou un débutant ne comprenant pas bien ces concepts.

(*) A vrai dire les boucles for parallèles ont rarement d'intérêt : c'est surtout adapté pour le parallélisme de données alors que la plupart des problèmes rencontrés relèvent du parallélisme de tâches. Par ailleurs sur appareil grand public ou de plus en plus de serveurs le parallélisme de données est confié au GPU plutôt qu'au CPU.

et soit persuadé que les programmeurs à la page (ceux qui pratiquent le C#, entre autres) sont constamment sur la brèche quand il s'agit d'intégrer de nouveaux concepts ou de nouvelles techniques (voir son affirmation dans un post précédent

J'ai simplement fait le constat, que tout observateur de ces écosystèmes pourra confirmer, que les nouveautés de ces langages sont rapidement adoptées par ces communautés. Il suffit de regarder les sources dispos sur github & co : les projets sortis après une nouvelle versions intègrent presque tous les nouveautés. Tu verras que bientôt les sources Java pulluleront des dernières fonctionnalités du langage.

C'est un article concernant le C# sur un site sérieux qui filtre ses publications. L'auteur nous montre qu'il est très pénalisant en termes de vitesse d'exécution du code d'employer un contrôle des exceptions. Un problème pour DonQuiche, c'est que la méthode la plus rapide (sauf en programmation linéaire pour 1000 itérations) n'est pas celle qui a raccourci le code au maximum en employant des outils du C#, mais la méthode "ancienne" qui consiste à tester par un if avant d'exécuter une/des instruction(s)

La méthode "ancienne" pénalise le chemin d'exécution sans erreur mais offre un chemin d'exécution avec erreur rapide.
La méthode "nouvelle" améliore le chemin d'exécution sans erreur mais rend le chemin d'exécution avec erreur très lent.

La raison en est simple : dans la méthode "ancienne" le chemin normal est pavé par des branchements conditionnels pour tester les erreurs. Dans la méthode "nouvelle" on vire l'intégralité de ces branchements et on se contente d'ajouter au binaire une table qui donne pour chaque offset dans la pile d'appels un code à exécuter. Lors d'un "throw" la pile d'appels est parcourue et tous les codes exécutés via longjmp.

La nouvelle méthode est évidemment préférable, raison pour laquelle le C++ et bien d'autres l'on adopté, et ton intervention m'a bien amusée.

Second problème pour DonQuiche : la démonstration fournie par l'auteur est un exemple d'utilisation des exceptions à proscrire

Non, elles sont à réserver aux situations exceptionnelles. Et c'est très bien comme ça. Surtout dans la mesure où cela permet de simplifier et accélérer le code normal.

Apparemment vous avez oublié comment se terminait votre premier message, alors je vous le cite :

En quoi est-il offensant de dire qu'un compilateur peut écrire plusieurs des codes que nous écrivons manuellement dans les vieux langages ? C'est la stricte vérité.

Je déteste me répéter. Chaque fois qu'un langage me force à écrire pour le n-ème fois le même motif, je le maudis. Et cela nous arrive à tous, tous les jours.

Et voici, pour mémoire encore, un autre échantillon de votre courtoisie :

En quoi est-il discourtois d'affirmer que je me "cogne" de défendre c# ? Tu peux trouver la formulation grossière mais pas discourtoise.

[DonQuiche]

Elle est pas mal celle là : le framework .Net doit être installé pour que le programme fonctionne non ?

Je voulais dire par là qu'aucun code tiers n'est appelé.

A part ça, tout programme dans quelque langage que ce soit peut être compilé en un seul binaire sans dépendance ou dans un binaire s'appuyant sur des dll pré-installées (mscvrt pour c++ sous Windows par exemple).

Et encore une fois on s'en fiche du c# : c'est pas parce que j'ai filé des exemples dans ce langage à quelqu'un qui disait le connaître qu'il faut tourner ça en une guerre c#/pascal, ce n'est pas le propos.

Développes tu dans le domaine des jeux vidéos ? Si oui, ça expliquerait certaines de tes positions.

Non, ce n'est pas mon domaine. Mais je suis en contact avec lui.

Si une entreprise dispose de compétences dans un langage et que ce langage est en capacité à répondre aux besoins utilisateurs, je ne pense pas que l'entreprise va se lancer dans une techno qu'elle ne maitrise pas (les infra seront peut être à modifier, le personnel à former, logiciels à remplacer, l'ingénierie de dev à revoir, et les délais du projet seront plus longs le temps que les équipes montent en compétences...). Le coût c'est un tout et pas seulement l'acquisition d'un produit.

C'est une question de rentabilité annuelle, de durée d'amortissement et de dette technique. Mais je ne suis pas sûr que dans toutes les entreprises on fasse vraiment l'effort de l'évaluer.

Je pense que tu serais surpris du nombres de flux financiers qui passent par du cobol dans le monde chaque jour (même à partir de sites web) !

Malheureusement, non, je n'en serais pas surpris du tout. Oui le Cobol est encore très présent. Oui dans un demi-siècle on recrutera encore deux ou trois programmeurs Cobol. Ça n'empêche pas d'être un langage mort car réservé à la maintenance ou à l'interopérabilité avec la dette technique acquise.

[gvasseur58]

Qui ici a déjà fait de la programmation procédurale, impérative, objet, logique, par contrainte, fonctionnelle, par acteurs, et manipulé des grammaires ? Qui ici a au moins étrenné un nouveau langage depuis le début de l'année ? Davantage ?

Je suis au contraire toujours à l'affût de nouveaux paradigmes. Tout le monde ici peut-il en dire autant ? Certains ne se sont-ils pas simplement habitués à manipuler le même langage depuis trop longtemps ?

Quitte à me re-répéter, je ne crois pas qu'il y ait une querelle des anciens contre les modernes, mais plutôt une propension bien humaine à défendre ce qu'on connaît, voire à combattre tout ce qui sort du champ de ce qu'on pense être le VRAI. Ça me fait penser à Bouvard et Pécuchet de Flaubert : les deux héros pensent qu'en multipliant les expériences et en couvrant l'ensemble du champ des connaissances, ils vont comprendre le monde... Ils étaient à leur manière toujours à "l'affût de nouveaux paradigmes" : en quoi est-ce une qualité en soi ? En quoi est-ce LA vérité ?

Pour être franc, comme tu l'as été avec Matthius, je me réserve le droit de ne plus te répondre, aucun argument ne trouvant grâce à tes yeux. Pour l'article que j'ai cité et qui concernait le C#, tu trouves encore le moyen de soutenir qu'une solution pourrie dans un cas précis est encore la meilleure... Ne peux-tu reconnaître que celui qui a proposé le code est pour le moins léger d'avoir utilisé à des fins pédagogiques les exceptions dans une situation aussi peu recommandable (ce que sait un programmeur un peu aguerri) ? Idem en ce qui concerne le parallélisme : ne confonds-tu pas allègrement des travaux théoriques (tu pouvais remonter dans les années 70 avec Flynn, non ?) et l'apport de techniques qui permettent aux programmeurs de faciliter l'exploitation des nouveaux processeurs ?...
En un mot, pourrais-tu admettre que la situation concrète de développement est peut-être moins intéressante qu'un débat sur les avantages de telle ou telle technique de programmation, mais autrement primordiale quand on est engagé dans un projet ? Je vois bien un client venir demander à un programmeur s'il n'a pas oublié d'utiliser les "yield return" Pour le confort du programmeur, pourquoi pas, mais à condition qu'il n'ait pas à passer tout son temps à se former dans l'action...

[DonQuiche]

Ne peux-tu reconnaître que celui qui a proposé le code est pour le moins léger d'avoir utilisé à des fins pédagogiques les exceptions dans une situation aussi peu recommandable (ce que sait un programmeur un peu aguerri) ?

A vrai dire je n'avais pas été voir la page proposée, je m'en excuse, et j'ai cru que tu traitais simplement des performances des exceptions.

Je viens d'aller le voir et je ne comprends même pas ce que tu essaies de prouver : la méthode 1 n'est pas l'ancienne, et l'utilisation qui est faîte ici des exceptions est tout simplement stupide et contraire à toutes les bonnes pratiques recommandée, à plus d'un titre (on ne doit pas faire de bloc catch généraliste et ce n'est pas une alternative au contrôle des flux).

Ce code est stupide, cet article est stupide.

Je ne comprends même pas pourquoi tu l'as mentionné, ça ne prouve rien à propos de Pascal, de C#, ou du débat exceptions contre vérifications. Ça prouve seulement que l'article est stupide et que les exceptions n'ont jamais été un substitut au contrôle des flux, seulement une méthode de gestion des erreurs inattendues comme un verrou sur un fichier ou une carence de mémoire.

C'est comme prétendre qu'il ne faut pas acheter de voiture parce que tu as vu un article prouvant que les BMW ne sont pas amphibies.

Idem en ce qui concerne le parallélisme : ne confonds-tu pas allègrement des travaux théoriques (tu pouvais remonter dans les années 70 avec Flynn, non ?) et l'apport de techniques qui permettent aux programmeurs de faciliter l'exploitation des nouveaux processeurs ?...

Non, dès les années 70 il y avait des ordinateurs dotés de plusieurs processeurs et des gens qui les programmaient. Autant dire que des boucles parallèles sont apparues immédiatement, même si à l'époque elles étaient manuellement implémentées.

Comme je l'ai dit MPI et OpenMP sont apparues parce que ces pratiques étaient suffisamment mûres et répandues pour les standardiser et promouvoir des constructions syntaxiques dédiées. En fait dans les 90's on en était déjà au stade où certaines stations de bureau avaient plusieurs processeurs !

En un mot, pourrais-tu admettre que la situation concrète de développement est peut-être moins intéressante qu'un débat sur les avantages de telle ou telle technique de programmation, mais autrement primordiale quand on est engagé dans un projet ?

Est-ce que l'important est de livrer un produit fonctionnel et conforme aux attentes ? Bien sûr.
Mais en quoi est-ce que ça rendrait secondaire le fait de savoir s'il est possible de réduire significativement les coûts de développement et de maintenance ?

A nouveau j'ai l'impression que tu veux nous faire avaler que tant que ça marche pas de souci et au diable la productivité, ou que parfois on n'a pas besoin de voiture parce qu'on pourrait avoir besoin de nager 100m à un moment.

[gvasseur58]

A nouveau j'ai l'impression que tu veux nous faire avaler que tant que ça marche pas de souci et au diable la productivité, ou que parfois on n'a pas besoin de voiture parce qu'on pourrait avoir besoin de nager 100m à un moment.

Quel est le véhicule le plus rapide ? L'avion ? Le train ? La voiture ? Le vélo ?
Si l'on écoute ton raisonnement, c'est évidemment l'avion et le vélo serait déjà enterré (ou plutôt serait mort-vivant pour 50 ans, mais avec deux ou trois ingénieurs qui essayeraient de l'améliorer). Dans l'absolu, c'est l'évidence...
Or, la réponse est tout à fait différente dans la réalité :
1. le vélo est de loin le véhicule le plus rapide dans une zone urbanisée pour des déplacements jusqu'à 4 km ;
2. la voiture se défend bien jusqu'à une centaine de kilomètres en zones urbaine et rurale ;
3. le train est idéal jusqu'à 500 km ;
4. l'avion bat tout le monde au-delà, à condition de trouver un... aéroport.
Et encore, j'ai à dessein fortement simplifier le tableau !
=> Je t'invite donc de nouveau à modérer tes affirmations (et à oser des oui francs et massifs) en n'oubliant pas ce qu'ont proposé certains intervenants ici : la productivité inclut la formation, l'appropriation des outils, la réinvention éventuelle de la roue, la configuration du parc d'ordis, la maintenance, etc. Autant dire que le pseudo-débat sur la modernité de langages (que tu ne connais même pas/plus) peut laisser indifférent ou énerver quelque peu : les enjeux vont bien au-delà !

On peut imaginer un échange entre un Javasien et un CSharpien :
-

• Quelle honte ! Java n'autorise même pas la surcharge des opérateurs !
• Tu crois que C# fait mieux en ne supportant pas les implémentations anonymes d'interfaces et de classes abstraites, ce qui est le minimum aujourd'hui, non ?
• Ton Java n'a toujours pas de mode unsafe permettant l'arithmétique de pointeurs, laisse-moi rire !
• Oui, mais Java a des exceptions vérifiées, alors que les exceptions du C♯ ne sont pas vérifiées !
• C♯ supporte les indexeurs, les méthodes déléguées, et les événements, nananère, alors que ton Java se contente du patron de conception observateur !
• Oui mais ton C♯ ne supporte pas les implémentations anonymes d'interfaces et de classes abstraites, pas plus que les classes internes statiques, bisque bisque rage : comment fais-tu pour vivre sans ?
• ... [Remerciements à Wikipédia pour un comparatif qui, sans lui, aurait fait baisser ma productivité]

Il suffit qu'un CplusPlusien arrive pour regretter les templates absents dans C# et se moquer des applets... Et je ne parle même pas de l'arriéré de service qui utilise encore Pascal Le comique de situation et celui du vocabulaire suffisent largement : inutile d'ajouter trop de personnages, non ?

[Paul TOTH]

Est-ce que l'important est de livrer un produit fonctionnel et conforme aux attentes ? Bien sûr.
Mais en quoi est-ce que ça rendrait secondaire le fait de savoir s'il est possible de réduire significativement les coûts de développement et de maintenance ?

ça tombe bien, "réduire significativement les coûts de développement et de maintenance" c'est justement le créneau de Delphi

[DonQuiche]

Quel est le véhicule le plus rapide ? L'avion ? Le train ? La voiture ? Le vélo ?

L'argument vaudrait si les spécificités de Pascal n'étaient plus que des lacunes et s'il s'était placé sur un créneau singulier. Mais ce n'est pas le cas : parce qu'il ne pouvait plus être compétitif face au C et C++ sur leurs terrains il a tenté de faire de l'applicatif et du RAD où il se cogne de plein fouet à des solutions plus mûres, crées dès le départ pour ça, fortes de communautés plus riches, soutenues par des éditeurs avec plus de moyens.

Le langage est en retard et inadapté à ses prétentions modernes. Vous me dîtes que le framework, lui, au moins, est bien fichu. Peut-être. Mais d'autres ont aussi des frameworks très riches, en plus de langages très riches et adaptés.

On peut imaginer un échange entre un Javasien et un CSharpien :

On s'en fiche : tous deux sont des langages qui restent pour quelques temps encore à la pointe, tous deux sont valables et ont d'autres arguments que la dette technique. Ça ne me semble pas être le cas de Pascal.

Quant au C++, lui aussi est une vieillerie. Mais il est encore souvent indispensable, malheureusement, dans le domaine qui est le sien. J'ose espérer que son abandon va s'accélérer toutefois.

Je t'invite donc de nouveau à modérer tes affirmations (et à oser des oui francs et massifs)

Apparemment tu veux croire que j'aurais été convaincu par vos arguments et refuserais de l'admettre. Malheureusement c'est tout l'inverse : plus nous en parlons, plus je mets à jour mes connaissances sur Pascal et rafraîchis mes souvenirs, plus je suis convaincu de son obsolescence.

La seule chose sur laquelle je ne me prononce pas car il me faudrait passer des dizaines d'heures à approfondir cette solution c'est la force exacte de Firemonkey. Et autant dire que vu le reste je ne m'attends pas vraiment à la septième merveille du monde et que je préfère investir ce temps ailleurs.

en n'oubliant pas ce qu'ont proposé certains intervenants ici : la productivité inclut la formation, l'appropriation des outils, la réinvention éventuelle de la roue, la configuration du parc d'ordis, la maintenance, etc.

Bien sûr que des investissements sont nécessaires, j'ai déjà traité de ces aspects. Mais vous, avez-vous réellement étudié les bénéfices éventuels d'une migration vers d'autres solutions ?

D'ailleurs tu parles de maintenance mais je ne pense pas me tromper en disant que le bassin de main d’œuvre disponible pour Pascal rétrécit et vieillit. Et la dette technique se creuse, se creuse, se creuse...

ça tombe bien, "réduire significativement les coûts de développement et de maintenance" c'est justement le créneau de Delphi

Voilà qui est original, peu de langages ont ces objectifs. On doit donc pouvoir s'y fier, inutile d'argumenter.

[Paul TOTH]

L'argument vaudrait si les spécificités de Pascal n'étaient plus que des lacunes et s'il s'était placé sur un créneau singulier. Mais ce n'est pas le cas : parce qu'il ne pouvait plus être compétitif face au C et C++ sur leurs terrains il a tenté de faire de l'applicatif et du RAD où il se cogne de plein fouet à des solutions plus mûres, crées dès le départ pour ça, fortes de communautés plus riches, soutenues par des éditeurs avec plus de moyens.

Le langage est en retard et inadapté à ses prétentions modernes.[...]

voir plus bas...

Voilà qui est original, peu de langages ont ces objectifs. On doit donc pouvoir s'y fier, inutile d'argumenter.

voir plus haut...

Tu fais des affirmations gratuites sur un produit que tu ne connais pas et que tu juges selon des critères que tu n'énonces pas, tout cela sur un forum qui lui est dédié....du coup ton discours s'apparente à du troll sans intérêt.

[DonQuiche]

Tu fais des affirmations gratuites sur un produit que tu ne connais pas et que tu juges selon des critères que tu n'énonces pas, tout cela sur un forum qui lui est dédié....du coup ton discours s'apparente à du troll sans intérêt.

J'ai déjà argumenté tout ça. Tu as le droit de ne pas être d'accord mais ne viens pas me traiter de troll. Et par ailleurs j'ai aussi expliqué qu'au moment où j'ai écrit mon premier message je n'avais pas conscience que l'actu avait été postée ici.

[Paul TOTH]

je suis allez à la pêche à tes arguments...

Où est votre gestion automatisée ou semi-automatisée de la mémoire ?

elle est depuis Delphi 1 (il y a 20 ans) dans l'allocation/libération automatique des composants gérés par la sérialisation.

elle est dans le développement mobile avec l'ARC qui sera généralisé dans les prochaines versions...même si je n'en suis pas fan.

Où est votre système d'introspection ou de métaprogrammation intégré ?

Depuis Delphi 1 (il y a 20 ans) dans les RTTI qui ont été grandement simplifiés et étendus depuis.

Où sont vos compréhensions de liste et autres systèmes fonctionnels basés sur des lambdas pour traiter de façon ultra-concise les structures de données ?

C'est sans doute le point dans Delphi qui perturbe le plus les développeurs habitués a des langages qui proposent des tas de raccourcis pour créer la quantité pharaonique de code nécessaire pour afficher une liste de 3 éléments à l'écran.
Sous Delphi il n'est pas tout simplement pas nécessaire de passer par là.
C'est possible ceci dit, des développeurs Delphi se sont donner la peine de travailler sous Delphi comme on le fait dans d'autres environnements comme mORMot par exemple.

Combien de lignes vous faut-il démarrer un calcul sur un autre thread/serveur et synchroniser plusieurs processus ? Plus d'une ligne ? Beaucoup plus d'une ligne ? Beaucoup beaucoup plus d'une ligne ?

Aucune ligne, il suffit d'utiliser un composant et de cocher quelques propriétés. C'est la philosophie de Delphi, c'est ce qui a fait son succès avant dotNet et qui continue de plaire à ses développeurs. Même si le langage permet aussi de triturer les choses dans le code si c'est ton désir.

Votre compilateur vous avertit-il si vous violez par inadvertance l'isolation des données entre threads (sans l'avoir expressément autorisé) ou si créez une possibilité de deadlock ?

Je ne pense pas, mais je ne vois pas bien de quel cas tu parles. As-tu un exemple dans un autre langage ?

Etc. Ce ne sont pas des jugements de valeur.C'est une question de LOC et de robustesse.

tu fais aussi l'erreur de vouloir sous Delphi programmer comme dans un autre langage. Delphi n'est pas juste un compilateur, c'est tout un environnement de développement qui propose de solutions clés en main pour un tas de problème (pas tous évidemment) que l'on rencontre en développement d'application métier. Ignorer cela c'est comme faire du C en C++.

J'ai un problème avec le ludisme dans notre profession, avec des hordes de gens qui s'accrochent à leurs vieux langages et dénigrent systématiquement tout ce qui a été fait depuis. C'est mon combat perso (voir mon pseudo).

en fait là c'est toi qui dénigre un langage qui loin d'être vieux, continue à évoluer régulièrement depuis 20 ans. Il intègre des concepts qui proviennent d'autres langages, et de façon assez drôle de nouveaux langages réinventent ce qui existe sous Delphi depuis 20 ans.

J'ai lu l'actu. Donc parce que quelque chose durant le trimestre a fait qu'il y a eu plus de recherches sur Pascal, je dois en déduire qu'il y a un revival d'un langage qui n'apporte rien par rapport à tout ce qui est plus récent ? Non, je crois simplement que Lazarus a reçu une bonne communication et qu'il y a eu un effet nostalgie. Ou peut-être est-ce lié à sa position comme introduction à la programmation dans l'enseignement et avec la multiplication des cours à destination des très jeunes.

Ah oui, Delphi n'a jamais été un outil de développement massivement utilisé, quand le développement RAD était à ses débuts on trouvait plus de projet sous VB que sous Delphi...et pourtant la comparaison était vite faite. Je suis a peu près certain qu'il y a des tas de développement sous WinDEV...sur lequel je ne m'étendrais pas...bref la popularité d'un langage n'a jamais fait sa qualité...après tout, PHP n'est-il pas un des langages les plus populaire ?