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
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
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.
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.
Là il y a une méconnaissance totale de l'économie, du commerce, et une valorisation du trafic.Non, je l'ai déjà dit : la question est de savoir s'il offre le meilleur rapport qualité-prix.
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.
non, en premier lieu c'est la science des habitats même si pour beaucoup le mot écologie à pris une définition plus large.Envoyé par matthius
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
aucun rapport car le terme écologie est dans ce cas uniquement la partie "développement durable"La relation entre écologie et économie est proche
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 :
Cette phrase est équivalente à la suivante :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.
"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.
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).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.
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.
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.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.
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.Vision économique : Cela est-il réellement utile ?
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.
Elle est pas mal celle là : le framework .Net doit être installé pour que le programme fonctionne non ?
Pas de problème, je suis d'accord avec toi.
Développes tu dans le domaine des jeux vidéos ? Si oui, ça expliquerait certaines de tes positions.
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.
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.
Des preuves de ce que tu avances ? ou c'est une nouvelle hypothèse...
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).
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...).
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.
C'est ce que j'ai dit : le Pascal n'est pas le seul dans ce cas.
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.Envoyé par sergio_is_back
Tu le fais déjà par l'ensemble de tes réflexions, montrant par ailleurs qu'un logiciel pourrait te remplacer.
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.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.
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.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.
En comparant C# à Python ou Java tu dis donc que Visual studio n'est plus du DRA. Est-ce vrai ?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.
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.
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 :
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.]
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.
MPI et OpenMP ont en effet été introduits dans les 90's et sonnaient l'âge de la maturité pour ces concepts.Sinon, on s'explique mal que DonQuiche renvoie la programmation parallèle aux années 90 (voir le livre de Hodges)
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.
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.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
La méthode "ancienne" pénalise le chemin d'exécution sans erreur mais offre un chemin d'exécution avec erreur rapide.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 "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.
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.Second problème pour DonQuiche : la démonstration fournie par l'auteur est un exemple d'utilisation des exceptions à proscrire
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.
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.Et voici, pour mémoire encore, un autre échantillon de votre courtoisie :
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.
Non, ce n'est pas mon domaine. Mais je suis en contact avec lui.Développes tu dans le domaine des jeux vidéos ? Si oui, ça expliquerait certaines de tes positions.
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.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.
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.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) !
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...
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.
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.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 ?...
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 !
Est-ce que l'important est de livrer un produit fonctionnel et conforme aux attentes ? Bien sûr.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 ?
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.
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 ?
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 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.On peut imaginer un échange entre un Javasien et un CSharpien :
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.
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.Je t'invite donc de nouveau à modérer tes affirmations (et à oser des oui francs et massifs)
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.
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 ?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.
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...
Voilà qui est original, peu de langages ont ces objectifs. On doit donc pouvoir s'y fier, inutile d'argumenter.
voir plus bas...
voir plus haut...Voilà qui est original, peu de langages ont ces objectifs. On doit donc pouvoir s'y fier, inutile d'argumenter.
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.
je suis allez à la pêche à tes arguments...
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.
Depuis Delphi 1 (il y a 20 ans) dans les RTTI qui ont été grandement simplifiés et étendus depuis.
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.
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.
Je ne pense pas, mais je ne vois pas bien de quel cas tu parles. As-tu un exemple dans un autre langage ?
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++.
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.
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 ?
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager