Discussion :

[Paul TOTH]

Plutôt qu'une unique ligne de code avec un await tu vas donc ajouter un composant via un éditeur wysiwyg, qui va ensuite ajoute une méthode différente à ton code, dans laquelle tu vas écrire la suite de la séquence à un endroit distinct du début de la séquence où tu avais fait appel à une mystérieuse variable webServiceRequestComponent déclarée dans la partie auto-générée du formulaire. Et si ta séquence implique d'interroger trois méthodes d'un service web, il va te falloir trois composants avec un code scindé en quatre parties.

Et enfin bien sûr tout ça ne fonctionne que pour http. Quid de la lecture d'un gros fichier éventuellement sur un disque réseau mappé, quid d'une méthode asynchrone vers un agent, etc ?

Alors tu as beau me dire que vous passez par une belle UI et autre, le fait que tu doives basculer sur une UI, farfouiller dans les menus, tout ça pour générer un squelette de code, plutôt que de taper un simple fichu mot-clé me rend sceptique.

J'ai connu ce genre de composants : WinForms en C# avait (a sans doute toujours) les mêmes pour les timers. Personne que je connaisse ne les regrette. D'ailleurs dans le nouveau framework UI de Microsoft (WPF) cette habitude d'ajouter des composants non-UI a disparu.

mais on a compris que tu n'aimes pas les développements visuels et événementiel, c'est ton droit. Mais comparer l’extrême richesse des composants Delphi a un bête Timer C# c'est juste une ânerie. Et oui je préfère cocher quelques propriété sur un composant non visuel que de taper du XAML

Ceci dit, je dois te remercier, suite à ta dernière remarque j'ai regardé cette vidéo (désolé DVP remplace systématiquement le lien par une balise VIDEO)

j'adore son accent
Elle m'a fait comprendre pourquoi Embarcadero a mis au point LiveBindings

Celui-ci permet le même binding que WPF mais au lieu de le faire en XAML ou via des fenêtres peu pratiques pour ce que je puisse en juger dans la vidéo, tu le fais par un drag&drop. Et vers 5 mintues dans la vidéo tu verras que ça fonctionne pour afficher une BDD dans une grille sans une ligne de code ou de XML.

[DonQuiche]

mais on a compris que tu n'aimes pas les développements visuels et événementiel, c'est ton droit. Mais comparer l’extrême richesse des composants Delphi a un bête Timer C# c'est juste une ânerie. Et oui je préfère cocher quelques propriété sur un composant non visuel que de taper du XAML

Aucun code en XAML ne serait nécessaire puisque, justement, ce genre de choses ne relève pas de l'UI.

Ceci dit, je dois te remercier, suite à ta dernière remarque j'ai regardé cette vidéo (désolé DVP remplace systématiquement le lien par une balise VIDEO)

Je vais clarifier les choses tout de suite : je ne suis pas du tout fan de WPF. Leur idée de base était la bonne mais ils ont foiré la mise en oeuvre et aujourd'hui on trouve des choses bien plus sympa en javascript, et peut-être sous Android et iOS (je ne sais pas).

Cela dit si tu veux faire du databinding vers un dataset en WPF ça n'a rien de sorcier. En Xaml tu écris "Text = {MyColumn}" et en C# tu initialises ta fenêtre avec "myWindow.DataContext = myDataSet".

Le problème de WPF est plutôt que faire à la main la plomberie réactive est trop lourd. Mais Windev n'a aucune solution pour ça non plus : vos databindings sont statiques. Si ça ne vous pose pas de problème c'est simplement parce que vous ne cherchez même pas à faire des UI réactives, parce que Delphi est un outil de RAD conçu pour cracher du bête formulaire standard à la pelle et pas autre chose, comme l'était WinForms. Alors que WPF est conçu pour créer des UI riches, réactives, animées, comme tu en vois partout sur tablettes et mobiles. Deux frameworks différents pour deux besoins différents.

Malheureusement pour un outil de RAD la démo que tu as fourni est loin d'être impressionnante. Je te laisse par exemple comparer ton tuto à celui-ci pour Windev :

.

[Paul TOTH]

Malheureusement pour un outil de RAD la démo que tu as fourni est loin d'être impressionnante. Je te laisse par exemple comparer ton tuto à celui-ci pour Windev

AHAHAHA !!!! c'est de la mauvaise fois extraordinaire ou juste un aveuglement borné, j'arrête là.

[ALWEBER]

Don Quiche imagines un monde ou tout n'est que même langage. Esperanto ! Peut être est ce le monde que j'ai imaginé avec FMX , Object Pascal ou C++

[gbegreg]

Pour compléter cette discussion, ce mois ci encore Delphi/Pascal Objet monte au classement TIOBE : http://www.tiobe.com/index.php/conte...pci/index.html

[matthius]

Pour compléter cette discussion, ce mois ci encore Delphi/Pascal Objet monte au classement TIOBE : http://www.tiobe.com/index.php/conte...pci/index.html

Objective-C is really going into freefall. The last couple of months it is losing about 1% of market share per month. If this trend continues, Objective-C will leave the TIOBE index top 20 before the end of this year. The main cause of this is Apple's announcement last year to replace Objective-C by its new programming language Swift. The programming community embraced Swift because it fits the bill much better. Apart from this, there is also a trend to use C++ more frequently to program the lower layers of an iOS application.

[e-ric]

Je m'invite tardivement à ce joyeux troll... Ce la faisait longtemps que l'on en avait pas eu un comme cela et j'en remet une couche (une bonne couche même)

J'ai l'impression que tu as eu une expérience malheureuse avec Delphi. Tant d'acharnement à démonter Delphi, mais avec tellement d'autres langages pour le faire que cela est presque un compliment pour Delphi. Tu nous démontres surtout que tous ces langages ont des avantages mais qu'aucun d'eux ne les a tous. Ce n'est pas une véritable information, merci quand même.

Tu défends des idées techniques sans doute prodigieuses mais fort éloignées de la réalité de beaucoup de développeurs qui en général n'en ont rien à foutre, ayant d'autres chats à fouetter (toutes mes excuses à Brigitte Bardot). Je te propose donc de venir maintenir des programmes en milieu bancaire par exemple j'entends par là non pas des anomalies mais les programmes du coeur de métier, tu vas devenir dépressif si tu n'aimes pas les motifs répétitifs. Je suis désolé mais les personnes qui déballent tant de termes grandiloquents alors que cela est hors du sujet initial m'inspire toujours un peu de méfiance. En plus, tu méconnais l'ambiance qui règne sur cette partie du forum dont les piliers sont des véritables fans du Pascal (voire de spécialistes reconnus). Qu'il y ait parfois de excès d'enthousiasme, à l'occasion d'une nouvelle favorable assez rare actuellement dans notre écosystème, se comprend facilement Le développement c'est de la technique mais la composante émotionnelle (humaine) est difficile à éclipser. La première réponse de Guillaume ne laissait pas penser à une prétendue supériorité du Pascal sur autre chose.

Au final, tu me fais penser à un VRP qui cherche à fourguer ses derniers gadgets mais en se trompant de cible. Bref tu me sembles parler comme un livre.

Ca c'est pour les attaques directes, tes arguments m'ont chauffé les oreilles, ça me défoule de troller le troll.

Pourquoi une personne qui travaille en permanence avec le même "vieux" langage serait pire qu'un autre qui virevolte d'un langage à un autre. Il faut voir les résultats, le reste c'est du pipeau. Le discours techno, je connais un peu, derrière les grands arguments, il y aussi parfois de grands vides.

Je n'aime pas certains langages car il ne collent pas à ma façon de penser mais je ne vais pas emmerder leurs défenseurs pour les convaincre de passer à un autre langage plus moderne, contrairement à toi, je ne suis pas le Messie. (Bon il est vrai qu'une fois je me suis lâché sur Cobol, mais je subis plus ce langage que je ne travaille avec, désolé pour les forumeurs concernés)

C# et Java sont des langages peut-être supérieurs à Delphi si cela a du sens. Après il faut voir, Java est vachement bon mais quand on voit les acrobaties pour manipuler de simples chaînes de caractères, je suis bien content de bosser avec Delphi ou FPC. Delphi/FPC et tous les autres ont leurs faiblesses mais il faut faire avec.

En définitive, dans le choix d'un langage en milieu professionnel, c'est le pognon qui décide, M$ et Oracle (et Sun avant lui) l'ont bien compris, les arguments techniques ont en général secondaires, les décideurs regardent la pérennité de l'investissement, un de mes patrons me disait que l'on ne pouvait jamais reprocher à un DSI de choisir M$ car c'est le leader, rideau !. Le développeur gérera les problèmes liés au langage lui-même, il est payé pour ça. Les problèmes de rentabilité sont sans doute mieux étudiés que tu ne l'imagines. Après, cela dépend de ce que l'on entend par rentabilité.

Quant à l'intérêt des nouvelles techno en matière de langage, il y a sans doute du vrai mais la réalité est cruelle:

- Cobol reste, et pour longtemps, l'un des langages les plus utilisés, au revoir beau rêve... Simple problème économique, les banquiers et les assureurs et autres industriels se foutent éperdument du lambda-calcul, des itérateurs et du reste. Pour le choix du langage adapté au projet, des fois (souvent dans certains milieux), c'est Cobol ou ... Cobol ou encore Cobol. Pour le recrutement de 1 ou 2 développeurs à l'avenir tu repasseras, ce sont plutôt des bataillons. Remettre en question l'existant pour changer de langage sans autre raison n'est pas un sujet de discussion dans le monde réel.

- le niveau technique des projets est souvent à ras des pâquerettes, donc la sophistication du langage n'est pas toujours un argument recevable.

- le niveau technique moyen des développeurs est assez faible du fait de l'insuffisance de la formation et du temps passé sur l'outil (on a parfois d'autres choses à faire) d'une part et parce qu'en France il vaut mieux faire du fonctionnel et pas trop se vanter de ses capacités techniques si l'on veut "évoluer" d'autre part.

- je pense que pour la productivité, il faut passer du temps pour maîtriser le langage, son EDI éventuel et surtout ses bibliothèques (vieilles terminologie, normal, je fais du Pascal). Il faut connaître réellement les défauts et qualités de son outil et rester lucide sur ce qu'il est. Se jeter sur les nouveautés du moment ne permet pas de gain de productivité sauf pour agrémenter son CV (il suffit de discuter avec des commerciaux de SSII pour comprendre). La maîtrise demande du temps et façonne l'esprit, en changer peut prendre du temps, les développeurs sont des humains avec leur inertie. Les outils nouveaux sont souvent truffés de bugs et un compilo est un logiciel complexe.

- Le SQL intégré (à la linq) c'est sans doute bien mais bon du code SQL dans une chaîne ça marche aussi. Si tu voyais comment on fait des requêtes SQL dans le monde des mainframes...

- Plutôt que créer des tas de langages ou de frameworks, il vaudrait mieux renforcer ceux qui existent.

Pour ce qui est de la compréhension du code par un non-informaticien, je n'en vois pas l'intérêt. Cobol a été conçu dans cette optique, il fallait qu'un comptable anglophone puisse comprendre le code. Mais je n'ai jamais vu un comptable le faire. A chacun son taf !

Delphi a été retenu comme langage d'enseignement en Afrique du Sud au détriment de Java jugé trop compliqué entre autres, mais bon les Africains du Sud sont certainement des arriérés. Le choix d'un langage d'enseignement n'est absolument pas anodin.

Je précise mes préférences en termes de langages

- FreePascal ou Delphi (7, près je connais pas trop) car je suis à l'aise et plus productif. Pas de Yield en Pascal ben tant pis on fera sans...

- Python qui a réintroduit la programmation de loisir et la rapidité d'écriture sans se perdre dans des raffinements techniques excessifs.

- Eiffel aurait dû réussir mais malheureusement son éditeur n'est pas M$. Sa syntaxe et sa simplicité conceptuelle en font vraiment un modèle (je ne code pas en Eiffel mais le bouquin de Bertrand Meyer reste une référence, sans doute la jugeras-tu ancienne)

et je code majoritairement en Cobol actuellement (ce langage est une hérésie mais on fait avec). Mon contact avec C#+XAML ne m'a absolument pas convaincu, c'est compliqué, la syntaxe de C# est lourde et le lien entre le code et le XML est pas vraiment évident (avis perso). Pour la maintenabilité, c'est raté... En fait C# et son alter ego Java me font apprécier Python.

Etant en passe de devenir un dinosaure, écrire 20 lignes ou 1 seule ne me gêne pas, il suffit d'écrire assez vite (et cela en connaissant bien son outil), c'est vrai que si le compilateur génère le code lui-même on peut penser que c'est mieux mais comment en être sûr ? Un compilo est aussi écrit par des collègues (voire des juniors comme tu les cites à croire qu'eux seulement font des conneries) et assez souvent en C ou en C++, la possibilité de bug est toujours présente, les batteries de tests unitaires ne font pas tout.

Cdlt

[e-ric]

Don Quiche imagines un monde ou tout n'est que même langage. Esperanto ! Peut être est ce le monde que j'ai imaginé avec FMX , Object Pascal ou C++

L'Esperanto est un projet des plus louables, il n'a pour objectif que de servir de langue auxiliaire, ce n'est pas une langue de domination même si certains espérantistes avaient des projets plus radicaux.

[DonQuiche]

Oh ! Un post de plus commençant par des attaques ad hominem, comme c'est charmant. Si j'avais voulu vendre quelque chose, non seulement j'aurais mieux fait de citer un produit, mais ensuite je serais surtout le dernier des idiots car ce n'est certainement pas ainsi que l'on vend et communique. Et pour la quatrième ou cinquième fois, je ne savais pas que le sujet se trouvait dans cette section lors de mon post initial.

A part ça je suis ravi de savoir que cela ne te dérange pas de taper vingt lignes au lieu d'une seule proche des spécifications. Je suis également certain que tes vingt lignes ne contiendront pas davantage de bogues, ne demanderont pas davantage de tests et seront aussi faciles à lire qu'une seule ligne.

Quant au fait que je ne connaîtrais pas la vraie vie réelle des banques, et bien non et fort heureusement : il y a un très vaste monde au-delà du milieu extrêmement conservateur des banques. Et je sais pertinemment combien celles-ci sont conservatrices, parfois pour de bonnes raisons (c'est ce que leurs clients attendent d'elles), plus souvent parce que les hommes en place sont conservateurs.

Cela dit puisque tu as rangé Python dans l'informatique de loisir alors qu'il est le 4ème langage sur le plan de l'emploi, là où Cobol n'est que 22ème et Delphi 26ème, j'ose croire que la vraie vie du monde réel est plus proche de moi que de vous.

Enfin, non, nombre d'innovations ne peuvent pas être ajoutées comme des bibliothèques.

PS : Oui, XAML est une bouse. Mais le combo WPF+XAML reste malgré cela supérieur à à peu près tout ce que j'ai vue en termes d'UI "raffinées" (non-RAD).

[gbegreg]

Cela dit puisque tu as rangé Python dans l'informatique de loisir alors qu'il est le 4ème langage sur le plan de l'emploi, là où Cobol n'est que 22ème et Delphi 26ème, j'ose croire que la vraie vie du monde réel est plus proche de moi que de vous.

Le classement Spectrum permet (en monnayant) de pondérer à sa guise les critères... et ainsi obtenir des résultats à sa convenance. Je ne vois pas de critère qui concerne directement l'emploi (tu affirmes que Python est au 4ème rang pour l'emploi). Par contre, ce type de classement montre bien qu'il n'existe pas de langage miracle doué dans tous les domaines. Ce qui confirme ce que beaucoup ont signalé sur ce sujet. (au passage je note que Spectrum comptabilise HTML ou encore Arduino comme des langages de programmation...)

Ton lien renvoie vers une page où il faut payer... Voici d'autres données issues de Spectrum également et datant de la même époque que tes chiffres (juillet 2014) http://superdevresources.com/top-pro...anguages-2014/. Delphi apparait 8ième dans le classement du développement pour mobile... Tu n'en parles pas mais je te comprends : dans le monde réel, le développement mobile ne représente qu'une petite niche sans avenir

Le "très vaste monde au-delà du milieu extrêmement conservateur des banques" ne fonctionnerait pas si le milieu des banques n'existaient pas. Et il n'y a pas que les banques... je ne retrouve pas l'information, mais j'avais lu il y a quelques temps qu'une personne utilisait en moyenne quotidiennement une dizaine d'applications basées sur Cobol (consultation de ses comptes sur Internet, virement, déclaration à son assurance, réservation de billet de toutes sortes...). Tu disais connaitre le milieu du jeu vidéo : malgré la taille de ce marché par exemple, je pense qu'il y a à travers le monde bien plus de développeurs qui bossent dans la branche "informatique de gestion" que dans celle des jeux vidéos.

Enfin, les indices qui permettent d'estimer la notoriété des langages de programmation s'appuient et recoupent plusieurs informations. En particulier, les recherches effectuées dans les moteurs de recherche, les projets hébergés sur des sites tels que SourceForge ou GitHub... Cependant, je doute que les banques, assurances, grandes compagnies nationales ou multinationales... mettent leurs sources sur SourceForge ou GitHub. Les langages utilisés dans ces sociétés ont donc moins de chance d'occuper les premières places des indices. Pour ce qui est des statistiques via les recherches sur Internet, je constate que mon propre comportement face à un problème dépend du langage sur lequel je suis : sur Groovy, Java, PHP ou encore Python, je ne calcule même pas, c'est Internet direct. Pour Delphi, c'est 50% l'aide en ligne et 50% de recherche sur Internet. Pour Cobol, c'est 95% l'aide en ligne (ou le support éditeur) et 5% sur Internet. Ce qui joue aussi en plus que cette différence de comportement, c'est mon niveau de connaissance/maitrise du langage. Plus je maitrise un langage moins j'ai besoin de rechercher dans l'aide ou un exemple de code sur Internet. Du coup, même si j'utilise toujours quotidiennement mon langage préféré, je ne fais plus ou très peu augmenter ses stats. Par contre, sur un langage que je ne connais pas, je suis forcément amené à effectuer beaucoup de recherches et du coup j'augmente les stats pour ce dernier...

Enfin, non, nombre d'innovations ne peuvent pas être ajoutées comme des bibliothèques.

Pour moi, de telles innovations seraient apportées par de nouvelles instructions au jeu d'instruction du processeur ciblé. Du coup, n'importe quel compilateur compatible avec ces nouvelles instructions permettrait de bénéficier de ces innovations et du coup le langage correspondant au compilateur en bénéficierait également (nouveau mot clé, nouvelle méthode...).
Si les innovations dont tu parles ne nécessitent pas de nouvelles instructions assembleur, alors, elles peuvent être apportées comme des bibliothèques.

[DonQuiche]

Don Quiche imagines un monde ou tout n'est que même langage. Esperanto ! Peut être est ce le monde que j'ai imaginé avec FMX , Object Pascal ou C++

Par contre, ce type de classement montre bien qu'il n'existe pas de langage miracle doué dans tous les domaines.

Je rectifie les choses : je n'ai jamais prétendu qu'il ne faudrait qu'un seul langage, ce serait stupide. En revanche j'affirme qu'il faut utiliser les meilleurs langages et que nombre de langages ne se justifient plus que par la base de code accumulée voire le refus de certains de mettre à jour leurs connaissances.


Sur le classement IEEE, il n'est pas payant chez moi et il présente bien un classement "jobs" sur la "barre" la plus haute (il y a trois barres au-dessus du classement) ; Delphi y apparaît en 26 ème position. Quant au classement général, plus subjectif, de l'IEEE il place Scala au même niveau qu'Objective-C pour le dév mobile ce qui me fait doucement sourire, même si je considère Obj-C comme une plaie pour le développement (comme la grande majorité des dévs Apple apparemment vu la vitesse à laquelle Swift est en train de lui bouffer ses pdm).

Enfin de nos jours l'info de gestion passe rarement par Cobol et autres, comme en témoignent les chiffres de l'emploi. Bien des entreprises ont complètement abandonné ces vieilleries pour passer à java/dotnet. Si Cobol & co servent encore des besoins critiques, le marché de l'emploi prouve sans ambages qu'ils ne sont plus que minoritaires.

Pour moi, de telles innovations seraient apportées par de nouvelles instructions au jeu d'instruction du processeur ciblé.

Désolé mais tu ne connais pas du tout le problème et ce que tu nous dis là est hors-sujet et irréaliste. Tu es en train de confondre le problème de la fonctionnalité et sémantique (langage/bibliothèque) avec celle d'une accélération matérielle pas forcément pertinente, bénéfique ou possible, au choix selon les fonctionnalités.

Exemple : le GC, les transactions mémoires, la programmation réactive, les acteurs, l'inférence de types à la compilation. Les deux premières peuvent être accélérées par des innovations matérielles mais c'est complètement hors-sujet pour les autres. Et si dans tous les cas tu peux t'efforcer de proposer une bibliothèque pour ça, le résultat sera tellement immonde que personne ne l'utilisera.

Il faut accepter l'évolution. Demain on ne programmera ni en Cobol, ni en Pascal, ni en C++, ni en Java, ni en C#.

[e-ric]

Salut à tous

Un vrai plaisir de répondre à notre nouveau Pascal-killer...

Oh ! Un post de plus commençant par des attaques ad hominem, comme c'est charmant.

Avoues que tu l'as bien cherché. Mais comme je l'avais dit, c'est un plaisir de troller le troll. En tout cas, tu démarres au quart de tour.

Car troll il y a, Delphi ou FPC a des limites, c'est un fait, je pense que la plupart des fans de Pascal en sont parfaitement conscients, ce ne sont pas de sombres abrutis. Depuis que j'ai découvert Python, je me suis bien rendu compte que Pascal dans sa forme actuelle a pris un peu d'âge, certains constructions sont vieillottes mais il n'empêche qu'il reste agréable de travailler en Pascal, quoique tu en dises.
Les langages s'améliorent avec le temps et pour certains c'est plus lent, peu de sociétés promeuvent Pascal et donc les moyens humains pour son développement sont beaucoup plus limités, l'existence de FPC est pour moi une sorte de petit miracle.
Rappelons quand même qu'au lancement de Delphi (1995), M$ n'avait que VB et C++ à mettre en face (à peu de chose de près) et que c'est en débauchant le père de Delphi et en se faisant expulser de la communauté Java qu'il s'est mis à produire C# et .Net. M$ a beau jeu de vendre son C# lourdingue, il fournit l'OS et incruste .Net au plus profond de lui, le jeu est totalement pipé sans compter les API non documentées ou vendues à prix d'or, spécialité de la maison. Sans compter non plus les bourdes aberrantes de Borland. En fait, cela a plus été un problème de petit commerce qu'un problème technique.

Je pense que tes arguments sont sensés, tu as de nombreuses connaissances mais l'informatique n'est pas qu'affaire de techniques, loin s'en faut, sinon M$ aurait déjà coulé depuis longtemps. Windows est opaque, pourri de bugs et grâce à cela la cible préférée des (mauvais) pirates, et pourtant il est toujours là et tant mieux: on me fout la paix quand je suis sur Linux (pas besoin d'anti-malware et d'autre saloperies CPU-phages).

Cependant la façon dont tu présentes tes arguments font ressentir une agressivité de ta part sur ce langage.
Bon, il est vrai que si Pascal profitait de certains avancées récentes, ce serait mieux mais cela n'empêche pas de développer des choses sans. Comme les habitués de ce forum, j'aime coder avec Pascal avec ses défauts et ses qualités commes d'autres aiment travailler avec C#, Java, PHP ou Cobol. Il vaut mieux travailler avec l'outil que l'on maîtrise.

Si j'avais voulu vendre quelque chose, non seulement j'aurais mieux fait de citer un produit, mais ensuite je serais surtout le dernier des idiots car ce n'est certainement pas ainsi que l'on vend et communique.

Ton problème est peut-être un peu là, tu es sans doute trop proche du marketing, de la communication et des nouveautés coûte que coûte.
Je préfère le dialogue à la communication, c'est plus humain.

Et pour la quatrième ou cinquième fois, je ne savais pas que le sujet se trouvait dans cette section lors de mon post initial.

Passons, mais cela change quoi ? De toutes façons, l'actualité Pascal ne concerne plus grand monde.

A part ça je suis ravi de savoir que cela ne te dérange pas de taper vingt lignes au lieu d'une seule proche des spécifications. Je suis également certain que tes vingt lignes ne contiendront pas davantage de bogues, ne demanderont pas davantage de tests et seront aussi faciles à lire qu'une seule ligne.

Je te l'ai déjà dit, je suis un dinosaure. Avec Cobol, j'en vois d'autres ...
Après, 20 courtes lignes au lieu d'1 très longue, c'est un choix. Ton argument ne signifie pas grand chose. Je suis adepte de la concision du code mais s'il faut 20 lignes, je les écrits, c'est tout.
Pour les spécifications, elles ne sont pas toujours parfaites (quand elles existent) car ceux qui les écrivent doivent jongler entre deux métiers (celui des informaticiens et celui des futurs utilisateurs), pas toujours simple que cela soit clair pour l'un et pour l'autre. J'ai déjà vu des spécifications écrites par des spécialistes (MOA externalisée) avec une erreur grossière dans une formule avec une valeur absolue, ce qui ne m'avait pas rassurer sur le reste des documents.
Il est parfois difficile de concilier précision (et longueur des documents), réactivité et soucis du quotidien (documentations, suivi de production, supports aux utilisateurs, études), tout ce qui émaille la vie d'un développeur qui ne fait pas que pisser du code.
Sans parler de la disponibilité des gens du métier qui ont eux-mêmes des soucis ou se contrefichent des études informatiques même si cela les impacte plus tard.
J'ai une vision assez élargie du métier de développeur, non seulement on doit écrire des programmes mais il faut les suivre, ce n'est pas seulement leur "fabrication" qui importe.

Quant au fait que je ne connaîtrais pas la vraie vie réelle des banques, et bien non et fort heureusement : il y a un très vaste monde au-delà du milieu extrêmement conservateur des banques. Et je sais pertinemment combien celles-ci sont conservatrices, parfois pour de bonnes raisons (c'est ce que leurs clients attendent d'elles), plus souvent parce que les hommes en place sont conservateurs.

Ok, cependant les banques, les assurances tout ce qu'on appelle les grands comptes font la loi en termes de techno, c'est bien pour cela que Cobol est aussi vivant et que certains langages (même parfaits) ne percent pas.
Je n'ai spécialement pas choisi le monde des banques mais il faut être pragmatique, si tu as pu t'en éloigner à ton gré, tant mieux pour toi. Il n'empêche que cela existe et est loin d'être une part marginale du monde informatique (tu penseras à Cobol quand tu retireras des sous dans un DAB).

Cela dit puisque tu as rangé Python dans l'informatique de loisir alors qu'il est le 4ème langage sur le plan de l'emploi, là où Cobol n'est que 22ème et Delphi 26ème, j'ose croire que la vraie vie du monde réel est plus proche de moi que de vous.

C'est une petite maladresse de ma part, cela correspond à l'usage que j'en fais ne pouvant pas l'utiliser dans le cadre professionnel. En France, Python n'est pas encore très répandu, c'est d'ailleurs dommage, c'est un langage qui a de grandes qualités et aussi retenus comme langage d'enseignement (comme le fût Pascal, cela prouve aussi que ce n'est pas une tare). Enfin, apprécier un langage pour son aspect ludique ne le dévalorise pas bien au contraire.

Enfin, non, nombre d'innovations ne peuvent pas être ajoutées comme des bibliothèques.

De toutes façons, ce sera les bibliotèques internes du compilo qui absorberont ces innovations, cela facilitera le travail du développeur d'application mais pas celui du développeur du compilateur. Le problème sera de faire confiance au compilateur sans avoir toujours accès à ses sources.

PS : Oui, XAML est une bouse. Mais le combo WPF+XAML reste malgré cela supérieur à à peu près tout ce que j'ai vue en termes d'UI "raffinées" (non-RAD).

Sans doute, pour XAML on converge.

Sur le classement IEEE, il n'est pas payant chez moi et il présente bien un classement "jobs" sur la "barre" la plus haute (il y a trois barres au-dessus du classement) ; Delphi y apparaît en 26 ème position. Quant au classement général, plus subjectif, de l'IEEE il place Scala au même niveau qu'Objective-C pour le dév mobile ce qui me fait doucement sourire, même si je considère Obj-C comme une plaie pour le développement (comme la grande majorité des dévs Apple apparemment vu la vitesse à laquelle Swift est en train de lui bouffer ses pdm).

Un classement n' a pas valeur d'éternité, Cobol et Delphi ont aussi été des stars. En outre, il faut toujours se méfier des chiffres : qui les a produit et comment et sur la base de quelles données ?

Enfin de nos jours l'info de gestion passe rarement par Cobol et autres, comme en témoignent les chiffres de l'emploi. Bien des entreprises ont complètement abandonné ces vieilleries pour passer à java/dotnet. Si Cobol & co servent encore des besoins critiques, le marché de l'emploi prouve sans ambages qu'ils ne sont plus que minoritaires.

Pour l'info de gestion, quand tu consulteras ton compte en banque entre autres, tu pourras te dire: oh la belle appli Java, malheureusement, le coeur de métier a toutes les chances d'être réalisé en Cobol+DB2. La faiblesse des recrutements s'explique peut-être plus par les délocalisations que par le manque de besoin. Tu iras dire cela aux SSII qui courent après les cobolistes ces derniers temps, moi-même, bien que ne mettant pas trop mes compétences cobol en avant, suis sollicité.
Le marché de l'emploi ne reflètent que partiellement la composition des parcs informatiques et révèlent surtout les besoins du moment.

Il faut accepter l'évolution. Demain on ne programmera ni en Cobol, ni en Pascal, ni en C++, ni en Java, ni en C#.

On ne programmera plus du tout et on aura plus grand chose à se dire.Cependant, on a encore le temps d'en reparler.

Globalement, toi et moi divergeons par une vision différente de l'informatique voire une philosophie très différente. Quant à venir ici faire du prosélytisme technique et nous faire comprendre qu'on a rien compris, c'est quand même osé.

Bon Dimanche.

[gbegreg]

Enfin de nos jours l'info de gestion passe rarement par Cobol et autres, comme en témoignent les chiffres de l'emploi. Bien des entreprises ont complètement abandonné ces vieilleries pour passer à java/dotnet. Si Cobol & co servent encore des besoins critiques, le marché de l'emploi prouve sans ambages qu'ils ne sont plus que minoritaires.

Effectivement, tu ne connais pas ce domaine... Je l'ai déjà dit mais les écoles et les organismes de formations remettent le Cobol à leurs programmes alors qu'il avait disparu. C'est bien le signe que les entreprises en font la demande, les besoins sont réels et les compétences manquent. Dans le secteur de l'emploi, je trouve cela plus concret que d'aller contrôler le nombre de projets sur GitHub...
Je constate dans mon entourage que beaucoup de sociétés de services recherches des compétences Cobol également pour répondre aux sollicitations de leurs clients... et ça ça ne ressort pas dans les fameux indices !

Désolé mais tu ne connais pas du tout le problème et ce que tu nous dis là est hors-sujet et irréaliste. Tu es en train de confondre le problème de la fonctionnalité et sémantique (langage/bibliothèque) avec celle d'une accélération matérielle pas forcément pertinente, bénéfique ou possible, au choix selon les fonctionnalités.

Pour les évolutions de syntaxes et fonctionnalités, les langages évoluent continuellement (il suffit de regarder les normes des langages et les évolutions apportées à chaque nouvelle version). Et au final toutes les évolutions sont des artifices qui sont forcément traduits en code machine au final. Le langage ne fait pas tout : les outils autour contribuent grandement à simplifier la vie du développeur (IDE, intégration continue, automatisation des tests). Tu dis connaitre beaucoup de langages, tu t'intéresses à tous les nouveaux mais du coup tu ne peux que les effleurer et tu les abandonnes bien vite sans suivre leurs évolutions ultérieures. Après un bon coup de buzz, et de bons départs, on constate que Dart et Go par exemple retombent bien vite... WebAssembly pointe le bout de son nez, on verra combien de temps ça dure. En attendant, les langages existants et solidement implantés évoluent également. Les performances des premiers programmes Java par rapport à ceux écrient en C++ étaient catastrophiques. Maintenant, il y a toujours une différence mais beaucoup moins importante et significative. Je connais des développeurs Cobol qui font de l'objet (ben oui la notion "orienté objet" n'existait pas dans les années 50, mais le langage a évolué).

Tu te fais ensuite des idées sur ton premier ressenti et tu considères que ton avis est et reste le bon. Libre à toi chacun est libre mais annoncer que tu es plus proche que les autres de la réalité dénote une certaine suffisance... C'est la réalité peut être dans ton secteur d'activité mais je peux te retourner ta phrase : il existe un vaste monde au delà de ton domaine...

Pour les évolutions hardware, je me souviens du temps où les instructions MMX puis plus tard les SSE, 3D Now.... sont apparues. Tout le monde encensait ces instructions (c'était même devenu des arguments marketing). On attendait avec impatience une mise à jour du compilateur pour en bénéficier... Finalement, tout le monde les implémente, les utilise sans le savoir et c'est tombé dans l'oubli.

Il faut accepter l'évolution. Demain on ne programmera ni en Cobol, ni en Pascal, ni en C++, ni en Java, ni en C#.

Voir ma réponse précédent : évoluer ce n'est pas systématiquement changer. De plus, tu auras remarqué que les intervenants ont tous indiqué qu'ils manipulaient plusieurs langages. Les points de syntaxe qui te tiennent à coeur sont de simple effet de cosmétiques : tu peux toujours arranger ton code pour le rendre facilement lisible et maintenable.

Par contre, je suis convaincu que demain, on programmera encore en Cobol, C++, Java... car la base de code installée est trop importante pour s'en séparer. Le Go et le Dart pour ne citer qu'eux, j'en suis beaucoup moins sûr... Alors certes, on utilisera de nouveaux langages mais les vieilleries auront la peau dure ! Et puis après demain, on aura même plus besoin de programmer !

[Michel]

Cela va peut-être étonner quelques habitants de Troll-City mais en lisant ces posts, j'ai vraiment envie de me remettre à fond au Pascal !!
Merci à vous

[DonQuiche]

@e-ric
Non, tes accusations de malhonnêteté et de malfaisance n'étaient pas de ma responsabilité mais bien de la tienne. Il ne s'agit que d'un cas trop banal d'incivilité en ligne.

a) Java a peut-être perdu à cause du monopole de MS mais Delphi, lui, n'avait aucune raison de gagner.

C# était tout simplement mieux positionné : pour les besoins qu'il sert il avait pour lui son très riche framework, son GC, sa sécurité, une plus grande modernité, un outillage de très haut niveau (VS + intellisense), son interfaçage direct avec OLE (Office & co), et une plus grande facilité pour les programmeurs peu doués qui n'avaient plus à manipuler des pointeurs et autres. C'était exactement ce dont la grande majorité de l'industrie avait besoin, et par-dessus cela une solution de très haute qualité, très adaptée à un marché bien ciblé, avec de gros avantages par rapport aux concurrents.

Pascal a commencé sa vie comme langage pour les étudiants des 70's, puis il a voulu devenir LE langage objet applicatif, puis un langage RAD. Autrement dit il a chaque fois essayé d'être le langage pour le nouveau besoin du moment tout en demeurant universel, et n'a donc cessé de détruire son identité et d'avoir le derrière entre deux chaises. Perpétuellement inadapté.


b) Je passe plus de temps dans la technique que dans mes autres rôles et je ne cède en rien aux sirènes commerciales des nouveaux langages, très loin de là. D'ailleurs mon langage principal demeure encore le même depuis 15 ans même si j'ai bon espoir de pouvoir bientôt enfin le remiser. Tout simplement parce que j'ai trop conscience du fait que chaque langage se destine à certains besoins plutôt qu'à d'autres (plutôt qu'aux miens), et parce que je connais bien les limites de chaque paradigme.

Mais contrairement à la plupart des programmeurs j'évite de former un lien identitaire avec mon langage, et de prendre toute critique de ce dernier pour moi. Et je suis très exigeant : j'ai beaucoup trop conscience de répéter encore et toujours les mêmes tâches, et je cherche en permanence les solutions qui pourront m'éviter cela. C'est ce qui m'a conduit à changer de langage une fois, et qui va me faire changer à nouveau, et qui me fera à nouveau changer dans dix à vingt ans. Et c'est pourquoi j'ai tant de peine à comprendre des personnes qui trouvent normal de travailler avec des outils dépassés et inefficaces, de recoder toujours les mêmes motifs, etc.


c) Le reste de ton message est consacré à démontrer que les nouvelles fonctionnalités n'ont pas d'intérêt et qu'il y a un immense marché invisible pour Cobol et Pascal. A mes yeux ce n'est que de l'aveuglement - ou de l'ignorance. Exemple le plus notoire : les ramasse-miettes éliminent 80% des failles de sécurité et permettent de significativement réduire le coût des logiciels et le nombre de bogues.

d) Oui, le marché français IT est malheureusement assez triste et le secteur bancaire y occupe une place de poids, surtout dans le bassin parisien d'emploi. Assez peu ailleurs.


@gbegreg
a) Je n'ai jamais cru en Dart qui n'avait pas suffisamment d'intérêt pour un coût trop élevé. Go n'est vraiment profitable que pour des titans comme Google, et je doute de son futur ailleurs que dans certaines niches importantes. Accessoirement ce langage a été conçu pour être ennuyeux et rendre la programmation ennuyeuse (conçu pour être suffisamment simpliste et improductif pour que le dernier des idiots puisse ne rien faire de problématique et que personne ne puisse sortir du cadre).

WebAssembly (qui n'est pas un langage) a revanche un futur certain et tout tracé, et il sera LA solution incontournable pour obtenir des sites web rapides et je suis convaincu que dans moins de dix ans tous les compilateurs de tous les langages privilégieront d'abord la sortie wasm avant celle du x86 et de l'arm. Et le fait que tu n'en as pas conscience témoigne d'une belle incompréhension des dynamiques technologiques en cours.

b) Les instructions x86 ne sont certainement pas ignorées par ceux qui écrivent des compilateurs, tout comme les fonctionnalités des langages ne sont certainement pas ignorées par les programmeurs.

c) Coller une gestion semi-automatisée de la mémoire dans le C++ a débouché sur des signatures de méthodes à rallonge et peu lisibles, la conception de leurs itérateurs rend hyper-verbeuse et repoussante toute tentative d'approche fonctionnelle et paresseuse, et l'introduction de la mémoire transactionnelle va poser de nombreux problèmes car les bibliothèques existantes n'ont pas été conçues pour ça. Et j'ai des tonnes d'autres exemples.

Non tu ne peux pas empiler. Parfois il faut revoir toute la philosophie, la syntaxe et la bibliothèque standard.

[gbegreg]

Java a peut-être perdu à cause du monopole de MS mais Delphi, lui, n'avait aucune raison de gagner.

Java a peut être perdu ? Ah bon ? Une nouvelle fois : quelles sont tes sources ?

Delphi lui n'avait aucune raison chance de gagner : MS avait rapidement flairé la bonne affaire et recruté ses pères fondateurs (qui ont ensuite créés le framework .NET en se basant sur les travaux qu'ils avaient effectués sur la VCL) et Borland a fait de nombreuses erreurs et a laissé Delphi et C++ Builder dépérir. Depuis la reprise par Embarcadero, les évolutions sont nombreuses et le rebond est réel. D'ailleurs, ce que tu cites ensuite comme points qui ont fait le succès de C#, on les retrouve dans Delphi. Par contre, je suis d'accord avec toi sur le fait que la puissance de MS a écrasé Delphi (en reprenant au passage beaucoup de ses concepts) et avec des moyens d'une tout autre envergure (pubs, versions gratuites, poids de MS dans les entreprises et les universités...). Mais cela n'enlève en rien les avantages de Delphi (simplicité, éditeur d'interface graphique performant (pas simplement pour de petits formulaires comme tu le supposes dans un de tes posts), accès aux données aisées, Insight (c'est l'Intellisense de Delphi), exécutables pouvant être générés pour plusieurs plateformes... et en plus sans requérir de framework particulier sur la machine cible).

j'ai beaucoup trop conscience de répéter encore et toujours les mêmes tâches, et je cherche en permanence les solutions qui pourront m'éviter cela.

<HUMOUR>Plutôt que de saisir ton code au clavier, essaye la reconnaissance vocale </HUMOUR>
Rien ne t'empêche de coder proprement : crée tes propres classes et méthodes qui encapsulent tout ce qui t'es répétitif. Mais bon, je pense que tu trouverais cela trop long et fastidieux et que tu serais déjà passé à un autre langage.

il y a un immense marché invisible pour Cobol et Pascal

Franchement, non, je ne pense pas pour ce qui est du Pascal. En revanche, pour Cobol oui et ça n'a rien d'invisible.

il y a un immense marché invisible pour Cobol et Pascal. A mes yeux ce n'est que de l'aveuglement

le marché français IT est malheureusement assez triste et le secteur bancaire y occupe une place de poids, surtout dans le bassin parisien d'emploi. Assez peu ailleurs.

et non, ça n'est pas qu'en France ou dans le bassin parisien !

WebAssembly a revanche un futur certain et tout tracé, et il sera LA solution incontournable pour obtenir des sites web rapides et je suis convaincu que dans moins de dix ans tous les compilateurs de tous les langages privilégieront d'abord la sortie wasm avant celle du x86 et de l'arm.

Bien-sur que c'est une solution qui a un avenir à court terme... mais ça risque de ne jouer que sur la partie IHM : le coeur de l'application restera certainement inchangée. C'est le principe des guichets et du coffre fort : ton coeur de métier (le coffre fort) est commun à tous tes guichets (site internet, plateforme téléphonique, courrier, visite physique du client, partenaire....).

Et le fait que tu n'en as pas conscience témoigne d'une belle incompréhension des dynamiques technologiques en cours.

On voit là ta marque de fabrique ! Tu juges les gens comme les langages : tu ne connais pas, tu établis un postulat et tu en tires une conclusion.

Pour moi, les dynamiques technologiques ne s'arrêtent pas à alléger la syntaxe pour le développeur, ou à rendre le web plus rapide (wasm)... c'est aussi et surtout savoir stocker, traiter, analyser et sécuriser d'immenses volumes de données que nous générons. Je vois d'avantage les informatiques quantique et cognitive comme les véritables prochaines évolutions.

Les instructions x86 ne sont certainement pas ignorées par ceux qui écrivent des compilateurs

Encore heureux que ceux qui écrivent des compilateurs connaissent sur le bout des doigts l'architecture cible ! Ces personnes là sont des pointures et donc rares, et les jeux d'instruction contiennent un nombre "restreint" d'instruction (quelques centaines).
Ce que je voulais dire, c'est qu'à l'époque du MMX c'était même indiqué dans les pubs au grand public : le néophyte voulant acheter son premier ordi, s'assurait auprès du vendeur qu'il s'agissait bien d'un Pentium MMX...

tout comme les fonctionnalités des langages ne sont certainement pas ignorées par les programmeurs

Là par contre, je nuancerai par "tout comme les principales fonctionnalités des langages...". Les programmeurs représentent déjà beaucoup plus de monde de niveau varié, et les langages contiennent de très nombreuses fonctionnalités. Ajouter à cela, qu'un programmeur doit connaitre plusieurs langages... Je connais assez bien Delphi mais je suis loin de connaitre toutes les fonctionnalités du langage par exemple.

[e-ric]

@e-ric
Non, tes accusations de malhonnêteté et de malfaisance n'étaient pas de ma responsabilité mais bien de la tienne. Il ne s'agit que d'un cas trop banal d'incivilité en ligne.

Prends cela pour de la rigolade et ça ira mieux. Bon on va arrêter de jouer sur ce registre, c'était pour le fun.

a) Java a peut-être perdu à cause du monopole de MS mais Delphi, lui, n'avait aucune raison de gagner.

C# était tout simplement mieux positionné : pour les besoins qu'il sert il avait pour lui son très riche framework, son GC, sa sécurité, une plus grande modernité, un outillage de très haut niveau (VS + intellisense), son interfaçage direct avec OLE (Office & co), et une plus grande facilité pour les programmeurs peu doués qui n'avaient plus à manipuler des pointeurs et autres. C'était exactement ce dont la grande majorité de l'industrie avait besoin, et par-dessus cela une solution de très haute qualité, très adaptée à un marché bien ciblé, avec de gros avantages par rapport aux concurrents.

Passons sur les qualités techniques, la présence d'un GC simplifie effectivement bien les choses. L'emploi des pointeurs n'est pas quelque chose qu'un développeur puisse ignorer. L'un des avantages de C# sur Java, est justement de permettre l'usage des pointeurs.

C'est ce qui m'a conduit à changer de langage une fois, et qui va me faire changer à nouveau, et qui me fera à nouveau changer dans dix à vingt ans. Et c'est pourquoi j'ai tant de peine à comprendre des personnes qui trouvent normal de travailler avec des outils dépassés et inefficaces, de recoder toujours les mêmes motifs, etc.

Encore faut-il trouver un employeur qui ne demande pas 5 ans d'expérience sur un langage qui vient de sortir ...
Ce n'est pas tant que l'on trouve cela normal, mais il y a beaucoup de projets informatiques qui ne sont que des maintenance de logiciels existants qu'il ne s'agit pas de réécrire complétement. Je ne trouve pas irrationnel de préserver un investissement humain, une personne qui a acquis une grande expérience et qui est en pleine maîtrise de l'outil n'a pas forcément envie de tout remettre en question, son employeur encore moins. Je t'assure que dans pas mal de grosses boîtes, ce discours aurait beaucoup de mal à passer. Tu peux prendre cela pour du conservatisme, j'en conviens mais je pense que cela est propre aux grosses organisations.
Je travaille actuellement pour une banque (son nom importe peu ici), le nombre de programme écrits fait qu'il est très difficile de chercher à réformer l'existant. Quant à changer de langage, ou pire de façon de penser... Si cela se fait, ce ne peut être que très progressif.

c) Le reste de ton message est consacré à démontrer que les nouvelles fonctionnalités n'ont pas d'intérêt et qu'il y a un immense marché invisible pour Cobol et Pascal. A mes yeux ce n'est que de l'aveuglement - ou de l'ignorance. Exemple le plus notoire : les ramasse-miettes éliminent 80% des failles de sécurité et permettent de significativement réduire le coût des logiciels et le nombre de bogues.

Je ne dénie pas l'intérêt des nouvelles fonctionnalités mais les préoccupations de ceux qui les créée (éditeurs, chercheurs) et celles des utilisateurs (développeurs) n'ont parfois pas grand chose à voir ensemble. Connaissant Python et codant en Cobol, je pense être assez bien placé pour voir les abysses qui les séparent.
Quant à l'ignorance et l'aveuglement, je ne suis pas d'accord avec toi. Je connais certainement moins de choses que toi sur ces sujets récents, je ne m'y intéresse guère a fortiori dans le poste que j'occupe actuellement. Plutôt que me disperser sur des sujets qui n'auront pas d'application dans le cadre de mon travail actuel, je préférais avoir une solide formation sur les mainframes en général ou sur C#. Mais bon les formations, on ne les a pas en claquant des doigts.
J'ai essayé de vendre Python à mon commercial, au début il connaissait même pas le nom. Pourquoi? parce que ses clients (grands comptes) n'en font aucune demande. On me demande rarement mon avis sur le choix des outils notamment quand je travaille chez un client.

d) Oui, le marché français IT est malheureusement assez triste et le secteur bancaire y occupe une place de poids, surtout dans le bassin parisien d'emploi. Assez peu ailleurs.

Et pas que là, recherche un peu dans le domaine de l'industrie (en informatique de gestion), tu seras peut-être surpris.

WebAssembly (qui n'est pas un langage) a revanche un futur certain et tout tracé, et il sera LA solution incontournable pour obtenir des sites web rapides et je suis convaincu que dans moins de dix ans tous les compilateurs de tous les langages privilégieront d'abord la sortie wasm avant celle du x86 et de l'arm. Et le fait que tu n'en as pas conscience témoigne d'une belle incompréhension des dynamiques technologiques en cours.

Peut-être, Delphi était promis à un avenir radieux dans les années 2000, maintenant... L'histoire a une propriété fondamentale, c'est la contingence. Une idée même extrêmement brillante n'aboutit pas forcément à la généralisation de son application. On verra donc cela dans 10 ans, je ne suis pas devin.

c) Coller une gestion semi-automatisée de la mémoire dans le C++ a débouché sur des signatures de méthodes à rallonge et peu lisibles, la conception de leurs itérateurs rend hyper-verbeuse et repoussante toute tentative d'approche fonctionnelle et paresseuse, et l'introduction de la mémoire transactionnelle va poser de nombreux problèmes car les bibliothèques existantes n'ont pas été conçues pour ça. Et j'ai des tonnes d'autres exemples.

Ca n'empêche pas C++ de fleurir sur le marché et les spécialistes en vivent bien. Perso, je n'aime pas trop C++, syntaxe obscure et sémantique aride, Eiffel lui était largement supérieur mais ATT n'était pas derrière Eiffel. Encore un bel exemple de rationalité dans le monde de l'informatique.

[DonQuiche]

Oui, la présence d'un GC "simplifie bien les choses", c'est peu de le dire, tout comme de très nombreuses autres fonctionnalités récentes. Elles méritent beaucoup plus qu'un "cela ne me dérange pas de taper vingt lignes". Et pourtant tu recommences : après les fonctionnalités qui n'ont pas d'intérêt, voici les fonctionnalités qui ne sont pas en phase avec les vrais besoins des vrais utilisateurs. Étrange, je dois être un faux utilisateur. C'est à se demander pourquoi certains dans l'industrie adoptent ces nouveaux langages.

a) Python n'est de toute façon pas fait pour l'entreprise : un typage dynamique convient très bien aux petits projets, pas aux moyens et gros. Son succès est dû au fait qu'il est plaisant, simple à apprendre, et que la quasi-totalité des universités américaines en ont fait leur langage d'introduction. Python en entreprise ne se justifie en général que par la facilité de recrutement et la satisfaction de l'équipe.

b) Sur les employeurs qui veulent tous cinq ans d'expérience, il y en a d'autres qui se laisseront convaincre. Et on peut se former soi-même plutôt que de demander une formation qui n'arrivera jamais et au cours de laquelle tu n'apprendras que le dixième de ce qu'il te faudra savoir parce que la communication orale est si lente, trop lente pour couvrir un langage qui nécessite un bon gros manuel de 300-500 pages.

c) Les pointeurs sont une blague dans C#, conçus pour les types valeurs car les GC compactent presque tous la mémoire et déplacent donc les objets lors de leur promotion.

d) Delphi était un langage propriétaire, un produit. Wasm est une ébauche de standard soutenu par la quasi-totalité des acteurs du marché.

e) Eiffel a une syntaxe volontairement verbeuse qui devient vite très ennuyeuse, et son GC ne le plaçait pas en concurrence avec C++ et en faisait un choix difficile pour l'époque (80's).

f) Oui ça n'a pas empêché le C++ de fleurir, et ça n'empêche pas non pus le monde entier de vouloir remplacer un C++ jugé anachronique et problématique malgré les empilements de couches récentes.



@gbegreg
Java a perdu au sens où il n'est pas devenu ce langage/plateforme universel qu'il aurait pu devenir. De nos jours Java est cantonné au serveur et à Android. Il prospère, il a un bel avenir, sans doute meilleur que celui de C#, mais il n'a pas accompli son destin. La faute conjointe à MS (qui l'a saboté) et à Sun (qui n'a jamais été foutu d'ajouter une bonne biblio UI et a exigé des royalties à MS en plus de saborder leur emprise).

[e-ric]

Pour commencer, excuses à Alcatîz, le sujet a largement dévié.

Oui, la présence d'un GC "simplifie bien les choses", c'est peu de le dire, tout comme de très nombreuses autres fonctionnalités récentes. Elles méritent beaucoup plus qu'un "cela ne me dérange pas de taper vingt lignes". Et pourtant tu recommences : après les fonctionnalités qui n'ont pas d'intérêt, voici les fonctionnalités qui ne sont pas en phase avec les vrais besoins des vrais utilisateurs. Étrange, je dois être un faux utilisateur. C'est à se demander pourquoi certains dans l'industrie adoptent ces nouveaux langages.

T'es un vrai enragé mais tu comprends tout de travers, prend la peine d'interprétrer correctement les propos des autres. Je n'ai jamais dis que cela n'avait pas d'intérêt, j'ai seumement que cela ne présentait pas le même intérêt pour tout le monde et que la décision du choix des outils revient rarement aux codeurs. Quant aux vrais utilisateurs, pour moi ce sont ceux qui utilisent les applications au quotidien, c'est envers que l'on est redevable. Les grandes idées des informaticiens, ils s'en tamponnent et ne veulent qu'un truc qui marche qu'il soit écrit en basic, en assembleur, en Delphi ou ce que tu veux. Je pense que là où je travaille tu n'aurais pas duré longtemps, tu n'es pas très conciliant.

a) Python n'est de toute façon pas fait pour l'entreprise : un typage dynamique convient très bien aux petits projets, pas aux moyens et gros. Son succès est dû au fait qu'il est plaisant, simple à apprendre, et que la quasi-totalité des universités américaines en ont fait leur langage d'introduction. Python en entreprise ne se justifie en général que par la facilité de recrutement et la satisfaction de l'équipe.

Tu iras proclamer tout cela dans le forum Python, connaissant un peu les personnages, l'acceuil risque d'être chaleureux, ou plutôt brûlant. Tu prouves ici ta condescendance. Il n'empêche que Django et Zope (entre autres)sont loin d'être des projets d'amateurs. Pour ta gouverne, Python est largement utilisé par Google (une bande d'étudiants bien connue) et fait partie des critères d'embauche. Au vu de l'échelle des salaires là-bas, je ne pense pas que cela soit fait pour le plaisir.

b) Sur les employeurs qui veulent tous cinq ans d'expérience, il y en a d'autres qui se laisseront convaincre. Et on peut se former soi-même plutôt que de demander une formation qui n'arrivera jamais et au cours de laquelle tu n'apprendras que le dixième de ce qu'il te faudra savoir parce que la communication orale est lente, trop lente pour couvrir un langage qui nécessite un bon gros manuel de 300-500 pages.

Même avec 20 ans d'expérience réelle, ils ne se laissent pas convaincre. La formation par soi-même c'est bien mais une formation est plus factuelle pour un recruteur, tout simplement (après ce qu'il y a dedans, la plupart du temps, ils ne le comprennent pas)

c) Les pointeurs sont une blague dans C#, conçus pour les types valeurs car les GC compactent presque tous la mémoire et déplacent donc les objets lors de leur promotion.

Une blague ? tu iras mettre en oeuvre une API de bas niveau sans eux... Petite question: est-ce que le GC tripote les objets non managés ?

d) Delphi était un langage propriétaire, un produit. Wasm est une ébauche de standard soutenu par la quasi-totalité des acteurs du marché.

. Wasm est une ébauche de standard donc pas encore un. D'ici à ce que les acteurs en question se mettent d'accord, wait and see.

e) Eiffel a une syntaxe volontairement verbeuse qui devient vite très ennuyeuse, et son GC ne le plaçait pas en concurrence avec C++ et en faisait un choix difficile pour l'époque (80's).

Verbeuse, pas plus qu'Ada oui Java. Mais Eiffel propose des mécanismes qui commencent seulement à être copiés par d'autres langages. La verbosité, c'est une question de surface, faut regarder le reste.

f) Oui ça n'a pas empêché le C++ de fleurir, et ça n'empêche pas non pus le monde entier de vouloir remplacer un C++ jugé anachronique et problématique malgré les empilements de couches récentes.

Le monde entier, c'est bien péremptoire... C++ est toujours là et la demande aussi. Ce sont peut-être bien les empilements qui le rendent problématique.

Mais au fait quels sont les miraculeux langages qui selon toi enfoncent tous les autres et dans quels projets (connus) sont-ils impliqués ?

[alheuredudejeuner]

Bonjour

Même avec 20 ans d'expérience réelle, ils ne se laissent pas convaincre. La formation par soi-même c'est bien mais une formation est plus factuelle pour un recruteur, tout simplement (après ce qu'il y a dedans, la plupart du temps, ils ne le comprennent pas)

Je confirme, une formation avec diplôme c'est mieux.
J'ai été recalé recalé une bonne dizaines de fois cette année.(finalement j'ai mon taf)
J’échoue à 90% des tests que je passe pour avoir un job de développeur Delphi.
J'ai réussi 100% des missions qu'on m'a confiées, même si quand j'arrive je suis complètement ignorant du sujet sur lequel je vais bosser.

Pourquoi je réussi ? parce que c'est relativement simple d'apprendre en Delphi (ou Lazarus), mais aussi grâce à la communauté Delphi très réactive.
Apprendre en Delphi, il y les faqs de Développez, mais depuis Thierry Laborde et les dev du jeudi, nous avons une grande variétés de vidéo tutos en Français.

Il y a 11 mois je déchargeais des camions sur un quai.( 30 ans de chef de dépôt, bac -3)
Aujourd'hui je suis développeur Delphi et fier de l'être.
Merci qui ? Merci a Delphi et à vous tous.

Je parle aussi C# et sql, bien qu'avec Transact-SQL je n'ai pas trouver toutes mes réponses ( oui, une formation officielle ce n'est pas du luxe.)

Cordialement

PS, je milite pour qu'une Delphi Académie puisse voir le jour